From david.black@emc.com Fri Jan 3 19:05:33 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536001AE033; Fri, 3 Jan 2014 19:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 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.538, 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 wfpgcsz16lUo; Fri, 3 Jan 2014 19:05:29 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7F11AE04A; Fri, 3 Jan 2014 19:05:29 -0800 (PST) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s0435ILq009213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jan 2014 22:05:19 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s0435ILq009213 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1388804719; bh=4343WqqOrPIjSi3bgycoA21UMss=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=eJk93ynU7WXjZGvW532ocg5acIHPxqu3AawoXE0v9xOhfwsvqehjyTDY0IrG+ol0+ AP/h0SpfmBw1DO4MMh+i1+1Tx8tgdNG+KR7eiyDasdavQQLxAf/nQRmC5JSa2yUYPY IDzI59sZU9BcKEW97bx1ELYu+Bncq+w1kS1GgdK0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s0435ILq009213 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd51.lss.emc.com (RSA Interceptor); Fri, 3 Jan 2014 22:05:01 -0500 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 s04350YW015161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jan 2014 22:05:01 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Fri, 3 Jan 2014 22:05:00 -0500 From: "Black, David" To: Jose Saldana , "tcmtf@ietf.org" , "tsv-area@ietf.org" Date: Fri, 3 Jan 2014 22:04:58 -0500 Subject: RE: TCMTF-Feedback about a possible BoF in London Thread-Topic: TCMTF-Feedback about a possible BoF in London Thread-Index: Ac79ZUO9+o1eWvDOTZW4bKGOX0YCWwLjYMDQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026EF2FF8F@MX15A.corp.emc.com> References: <00c401cefd65$6e8ef570$4bace050$@unizar.es> In-Reply-To: <00c401cefd65$6e8ef570$4bace050$@unizar.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE712026EF2FF8FMX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Cc: Martin Stiemerling X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 04 Jan 2014 03:05:33 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE712026EF2FF8FMX15Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A second BoF has the explicit goal of forming a WG, as a third BoF is not permitted. In that regard, the new charter seems long and somewhat lacking in focus. Two key things I look for in a proposed charter are what problem (or problems) the proposed WG is looking to solve and an initial approach to the problem or problems. In the new draft charter, the problem statement appears to be in paragraph 4 with paragraph 1 providing important background. The focus of the work appears to be on extending TCRTP (RFC 4170) to UDP and to include new compression protocols. In contrast, I have a hard time discerning the initial approach from the new draft charter. In light of this, there are a few things that I wish the new draft charter had definitive proposals for: a) Whether to replace RFC 4170 vs. write a new RFC (could be UDP-only or UDP + RTP/UDP) as a complement to RFC 4170. b) Whether to use ECRTP, ROHCv2 (RFC 5225) and/or IPHC (RFC 2507 ?). Non-use of ECRTP would be a major change to 4170, and I wonder about IPHC, as opposed to the ROHCv2 profiles. c) Analogies to b) for the Mux and Tunnel layers of the stack. Overall, it looks like the first task of the WG is to select the protocol stack to standardize - I have misgivings about that, and would prefer to see a concrete proposal in a crisp charter that ran along the following lines, naming the protocols to be used: 1) RFC 4170 does X, and needs the following changes/additions: X, Y, Z. 2) The WG will replace RFC 4170 with a new RFC that contains: A, B, C. A specific proposal or proposals for the protocol stack or stacks would also narrow the scope of item 9 in the charter on the negotiation mechanism. I also don't see a goal/milestone listed for an extension to or replacement for RFC 4170. I'd prefer to see a much shorter more focused draft charter. There's a bunch of background material that does not seem crucial to the charter, starting w/paragraphs 2 and 3. Thanks, --David From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Jose Saldana Sent: Friday, December 20, 2013 4:26 AM To: tcmtf@ietf.org; tsv-area@ietf.org Cc: Martin Stiemerling Subject: TCMTF-Feedback about a possible BoF in London Hi all, After the feedback received in the BoF in Berlin, we have updated the TCM-T= F charter and the two drafts. We have tried to solve all the problems raise= d during the session. Our plan is to request a new BoF in London next March, so we would like to = know your opinion about these two questions: 1. Is the new, reduced scope of TCM-TF suitable to form a working group? 2. We would like to kindly ask people who think that a TCM-TF Working group= should be formed, to come forward and send an e-mail to the tsv-area@ietf.= org mailing list stating it. This feedback will allow us to get a better idea of the convenience of a Bo= F. The new charter is here: http://www.ietf.org/mail-archive/web/tcmtf/current= /msg00465.html This is the old one (presented in Berlin): http://www.ietf.org/mail-archive= /web/tcmtf/current/msg00368.html In these links you can see the differences between the new versions of the = drafts and the old ones: http://tools.ietf.org/rfcdiff?url1=3Ddraft-saldana-tsvwg-tcmtf-06.txt&url2= =3Ddraft-saldana-tsvwg-tcmtf-05.txt http://tools.ietf.org/rfcdiff?url1=3Ddraft-suznjevic-tsvwg-mtd-tcmtf-02.txt= &url2=3Ddraft-suznjevic-tsvwg-mtd-tcmtf-01.txt The main improvements are: - TCP optimization has been removed - The classification of the scenarios has been refined and improved. Some o= f them have been removed - A section about energy consumption has been added to the main draft - A reference to the potential problem of the MTU and packet loss has been = added - The problem of the added delays is studied in detail in the second draft - The improvements of the charter are summarized here: http://www.ietf.org/= mail-archive/web/tcmtf/current/msg00466.html Best regards, Jose --_000_8D3D17ACE214DC429325B2B98F3AE712026EF2FF8FMX15Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A second BoF has the= explicit goal of forming a WG, as a third BoF

is not permitted.  In that regard, the new charter seems lon= g and

somewhat lacking in focus. = ; Two key things I look for in a proposed

charter are what problem (or problems) the proposed WG is looking to

solve and an initial approach to the p= roblem or problems.

 

In the new draft charter, the problem stateme= nt appears to be in

paragraph 4 wit= h paragraph 1 providing important background.  The

focus of the work appears to be on extending TCRTP (RFC = 4170) to

UDP and to include new compr= ession protocols.  In contrast, I have

a hard time discerning the initial approach from the new draft cha= rter.

 

In light of this, there are a few things that I wish the new<= o:p>

draft charter had definitive proposal= s for:

 

 = ;           UDP-only or U= DP + RTP/UDP) as a complement to RFC 4170.

      b) Whether to use ECRTP, ROHCv2 (RFC 5= 225) and/or IPHC (RFC 2507 ?).

 =            Non-use of ECR= TP would be a major change to 4170, and I

wonder about IPHC, as oppo= sed to the ROHCv2 profiles.

 &nb= sp;    c) Analogies to b) for the Mux and Tunnel layers of t= he stack.

 

Overall, it looks like the first task of the WG is to sel= ect the protocol

stack to standardize= - I have misgivings about that, and would prefer to

<= p class=3DMsoNormal>see a concrete proposal in a crisp charter that ran along t= he following

lines, naming the protoc= ols to be used:

 

1) RFC 4170 does X, and needs the following changes= /additions: X, Y, Z.

2) The WG will = replace RFC 4170 with a new RFC that contains: A, B, C.

 

A specific = proposal or proposals for the protocol stack or stacks

would also narrow the scope of item 9 in the charter on t= he negotiation

mechanism.  I als= o don’t see a goal/milestone listed for an extension to

or replacement for RFC 4170.

=

 

I’d pre= fer to see a much shorter more focused draft charter.  There’s a=

bunch of background material that do= es not seem crucial to the charter,

s= tarting w/paragraphs 2 and 3.

&n= bsp;

Thanks,
--David

<= /div>

 

From: tsv-area [mailto:tsv-area-bounces@ietf.org] O= n Behalf Of Jose Saldana
Sent: Friday, December 20, 2013 4:26= AM
To: tcmtf@ietf.org; tsv-area@ietf.org
Cc: Martin St= iemerling
Subject: TCMTF-Feedback about a possible BoF in London<= o:p>

 

=

Hi all,

 

After the feedback received in the BoF in Berlin, we have updated the TC= M-TF charter and the two drafts. We have tried to solve all the problems ra= ised during the session.

 

Our plan is to request a new BoF in London next = March, so we would like to know your opinion about these two questions:

 

<= o:p> 

1.  Is the new, reduced scope= of TCM-TF suitable to form a working group?

 

 

2. We would like to kindly ask people who think that a TCM-TF= Working group should be formed, to come forward and send an e-mail to the = tsv-area@ietf.org  mailing li= st stating it.

 

 

This feedback wi= ll allow us to get a better idea of the convenience of a BoF.

 

The new cha= rter is here: http://www.ietf.org/mail-archive/web/tcmtf/current/msg00465= .html

This is the old one (presented= in Berlin): http://www.ietf.org/mail-archive/web/tcmtf/current/msg00368.= html

 

In these links you can see the differences between the new ver= sions of the drafts and the old ones:

http://tools.ietf.org/rfcdiff?url1=3Ddraft-saldana-tsvwg-tcmtf-06.= txt&url2=3Ddraft-saldana-tsvwg-tcmtf-05.txt

http://tools.ietf.org/rfcdiff?url1=3Ddraft-suznjevic-tsvwg-mt= d-tcmtf-02.txt&url2=3Ddraft-suznjevic-tsvwg-mtd-tcmtf-01.txt

 

 

The main improvements are:=

 

- TCP op= timization has been removed

- The classi= fication of the scenarios has been refined and improved. Some of them have = been removed

- A section about energy co= nsumption has been added to the main draft

- A reference to the potential problem of the MTU and packet loss has be= en added

- The problem of the added dela= ys is studied in detail in the second draft

 

- The improvements of the cha= rter are summarized here: http://www.ietf.org/mail-archive/web/tcmtf/curr= ent/msg00466.html

 <= /p>

 

Best rega= rds,

 

Jose

 

<= /div>= --_000_8D3D17ACE214DC429325B2B98F3AE712026EF2FF8FMX15Acorpemcc_-- From jsaldana@unizar.es Sun Jan 5 10:47:50 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3821AF432; Sun, 5 Jan 2014 10:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.839 X-Spam-Level: X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 xYt7BGvIti5T; Sun, 5 Jan 2014 10:47:45 -0800 (PST) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8F16A1AF431; Sun, 5 Jan 2014 10:47:44 -0800 (PST) Received: from jsaldanapc (126.Red-88-4-241.dynamicIP.rima-tde.net [88.4.241.126]) (authenticated bits=0) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s05IlL8a014472; Sun, 5 Jan 2014 19:47:26 +0100 From: "Jose Saldana" To: "'Black, David'" , , References: <00c401cefd65$6e8ef570$4bace050$@unizar.es> <8D3D17ACE214DC429325B2B98F3AE712026EF2FF8F@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026EF2FF8F@MX15A.corp.emc.com> Subject: RE: TCMTF-Feedback about a possible BoF in London Date: Sun, 5 Jan 2014 19:47:24 +0100 Message-ID: <005101cf0a46$95ca10f0$c15e32d0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0052_01CF0A4E.F7935AF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKm4iuy1T4jUNWcvPCI8e0mPkHF7QHB3wddmLi5h+A= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: 'Martin Stiemerling' X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 05 Jan 2014 18:47:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0052_01CF0A4E.F7935AF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David, =20 Thanks for your valuable comments! =20 I will improve the charter according to your suggestions and release a = new version. =20 Thanks again, =20 Jose =20 De: Black, David [mailto:david.black@emc.com]=20 Enviado el: s=E1bado, 04 de enero de 2014 4:05 Para: Jose Saldana; tcmtf@ietf.org; tsv-area@ietf.org CC: Martin Stiemerling; Black, David Asunto: RE: TCMTF-Feedback about a possible BoF in London =20 A second BoF has the explicit goal of forming a WG, as a third BoF is not permitted. In that regard, the new charter seems long and somewhat lacking in focus. Two key things I look for in a proposed charter are what problem (or problems) the proposed WG is looking to solve and an initial approach to the problem or problems. =20 In the new draft charter, the problem statement appears to be in paragraph 4 with paragraph 1 providing important background. The focus of the work appears to be on extending TCRTP (RFC 4170) to UDP and to include new compression protocols. In contrast, I have a hard time discerning the initial approach from the new draft charter. =20 In light of this, there are a few things that I wish the new draft charter had definitive proposals for: =20 a) Whether to replace RFC 4170 vs. write a new RFC (could be UDP-only or UDP + RTP/UDP) as a complement to RFC 4170. b) Whether to use ECRTP, ROHCv2 (RFC 5225) and/or IPHC (RFC 2507 = ?). Non-use of ECRTP would be a major change to 4170, and I wonder about IPHC, as opposed to the ROHCv2 profiles. c) Analogies to b) for the Mux and Tunnel layers of the stack. =20 Overall, it looks like the first task of the WG is to select the = protocol stack to standardize - I have misgivings about that, and would prefer to see a concrete proposal in a crisp charter that ran along the following lines, naming the protocols to be used: =20 1) RFC 4170 does X, and needs the following changes/additions: X, Y, Z. 2) The WG will replace RFC 4170 with a new RFC that contains: A, B, C. =20 A specific proposal or proposals for the protocol stack or stacks would also narrow the scope of item 9 in the charter on the negotiation mechanism. I also don=92t see a goal/milestone listed for an extension = to or replacement for RFC 4170. =20 I=92d prefer to see a much shorter more focused draft charter. = There=92s a bunch of background material that does not seem crucial to the charter, starting w/paragraphs 2 and 3. =20 Thanks, --David =20 From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Jose = Saldana Sent: Friday, December 20, 2013 4:26 AM To: tcmtf@ietf.org; tsv-area@ietf.org Cc: Martin Stiemerling Subject: TCMTF-Feedback about a possible BoF in London =20 Hi all, =20 After the feedback received in the BoF in Berlin, we have updated the = TCM-TF charter and the two drafts. We have tried to solve all the problems = raised during the session. =20 Our plan is to request a new BoF in London next March, so we would like = to know your opinion about these two questions: =20 =20 1. Is the new, reduced scope of TCM-TF suitable to form a working = group? =20 =20 2. We would like to kindly ask people who think that a TCM-TF Working = group should be formed, to come forward and send an e-mail to the tsv-area@ietf.org mailing list stating it. =20 =20 This feedback will allow us to get a better idea of the convenience of a BoF. =20 The new charter is here: http://www.ietf.org/mail-archive/web/tcmtf/current/msg00465.html This is the old one (presented in Berlin): http://www.ietf.org/mail-archive/web/tcmtf/current/msg00368.html =20 In these links you can see the differences between the new versions of = the drafts and the old ones: =20 http://tools.ietf.org/rfcdiff?url1=3Ddraft-saldana-tsvwg-tcmtf-06.txt&url= 2=3Ddra ft-saldana-tsvwg-tcmtf-05.txt http://tools.ietf.org/rfcdiff?url1=3Ddraft-suznjevic-tsvwg-mtd-tcmtf-02.t= xt &url2=3Ddraft-suznjevic-tsvwg-mtd-tcmtf-01.txt =20 =20 The main improvements are: =20 - TCP optimization has been removed - The classification of the scenarios has been refined and improved. = Some of them have been removed - A section about energy consumption has been added to the main draft - A reference to the potential problem of the MTU and packet loss has = been added - The problem of the added delays is studied in detail in the second = draft =20 - The improvements of the charter are summarized here: http://www.ietf.org/mail-archive/web/tcmtf/current/msg00466.html =20 =20 Best regards, =20 Jose =20 ------=_NextPart_000_0052_01CF0A4E.F7935AF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

David,

 

Thanks for = your valuable comments!

 

I will = improve the charter according to your suggestions and release a new = version.

 

Thanks = again,

 

Jose

 

De: Black, = David [mailto:david.black@emc.com]
Enviado el: s=E1bado, 04 = de enero de 2014 4:05
Para: Jose Saldana; tcmtf@ietf.org; = tsv-area@ietf.org
CC: Martin Stiemerling; Black, = David
Asunto: RE: TCMTF-Feedback about a possible BoF in = London

 

A second BoF has the explicit goal of forming a WG, as = a third BoF

is not = permitted.  In that regard, the new charter seems long = and

somewhat lacking in focus.  Two key things I look = for in a proposed

charter are what problem (or problems) the proposed WG = is looking to

solve and an initial approach to the problem or = problems.

 

In the new draft charter, the problem statement = appears to be in

paragraph 4 with paragraph 1 providing important = background.  The

focus of the work appears to be on extending TCRTP = (RFC 4170) to

UDP and to include new compression protocols.  In = contrast, I have

a hard time discerning the initial approach from the = new draft charter.

 

In light of this, there are a few things that I wish = the new

draft = charter had definitive proposals for:

 

      a) Whether to replace = RFC 4170 vs. write a new RFC (could be

         &= nbsp;  UDP-only or UDP + RTP/UDP) as a complement to RFC = 4170.

      b) Whether to use = ECRTP, ROHCv2 (RFC 5225) and/or IPHC (RFC 2507 = ?).

         &= nbsp;  Non-use of ECRTP would be a major change to 4170, and = I

wonder = about IPHC, as opposed to the ROHCv2 profiles.

      c) Analogies to b) for = the Mux and Tunnel layers of the stack.

 

Overall, it looks like the first task of the WG is to = select the protocol

stack to standardize - I have misgivings about that, = and would prefer to

see a concrete proposal in a crisp charter that ran = along the following

lines, naming the protocols to be = used:

 

1) RFC 4170 does X, and needs the following = changes/additions: X, Y, Z.

2) The = WG will replace RFC 4170 with a new RFC that contains: A, B, = C.

 

A specific proposal or proposals for the protocol = stack or stacks

would also narrow the scope of item 9 in the charter = on the negotiation

mechanism.  I also don’t see a = goal/milestone listed for an extension to

or = replacement for RFC 4170.

 

I’d prefer to see a much shorter more focused = draft charter.  There’s a

bunch = of background material that does not seem crucial to the = charter,

starting w/paragraphs 2 and 3.

 

Thanks,
--David

 

From:= tsv-area = [mailto:tsv-area-bounces@ietf.or= g] On Behalf Of Jose Saldana
Sent: Friday, December = 20, 2013 4:26 AM
To: tcmtf@ietf.org; tsv-area@ietf.org
Cc: = Martin Stiemerling
Subject: TCMTF-Feedback about a possible = BoF in London

 

Hi all,

 

After the feedback received in the BoF in Berlin, we have = updated the TCM-TF charter and the two drafts. We have tried to solve = all the problems raised during the session.

 

Our plan is to request a new BoF in = London next March, so we would like to know your opinion about these two = questions:

 

 

1.  Is the new, reduced scope of TCM-TF suitable to = form a working group?

 

 

2. We would like to kindly ask people who think that a = TCM-TF Working group should be formed, to come forward and send an = e-mail to the tsv-area@ietf.org =  mailing list stating it.

 

 

This feedback will allow us to get = a better idea of the convenience of a BoF.

 

The new charter is here: http://www.ietf.org/mail-archive/web/tcmtf/current/msg00465.html

This is the = old one (presented in Berlin): http://www.ietf.org/mail-archive/web/tcmtf/current/msg00368.html

 

In these links you can see the differences between the new = versions of the drafts and the old ones:

http://tools.ietf.org/rfcdiff?url1=3Ddraft-saldana-tsvwg-tcm= tf-06.txt&url2=3Ddraft-saldana-tsvwg-tcmtf-05.txt

http://tool= s.ietf.org/rfcdiff?url1=3Ddraft-suznjevic-tsvwg-mtd-tcmtf-02.txt&url2= =3Ddraft-suznjevic-tsvwg-mtd-tcmtf-01.txt

 

 

The main improvements = are:

 

- TCP optimization has been removed

- The classification of the = scenarios has been refined and improved. Some of them have been = removed

- A = section about energy consumption has been added to the main = draft

- A = reference to the potential problem of the MTU and packet loss has been = added

- The = problem of the added delays is studied in detail in the second = draft

 

- The improvements of the charter are summarized here: http://www.ietf.org/mail-archive/web/tcmtf/current/msg00466.html

 

 

Best regards,

 

Jose

 

------=_NextPart_000_0052_01CF0A4E.F7935AF0-- From ggx@gigix.net Mon Jan 6 02:41:47 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917111ADFBF for ; Mon, 6 Jan 2014 02:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, 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 WhhVlNOdzGA3 for ; Mon, 6 Jan 2014 02:41:45 -0800 (PST) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id 09A701ADF8F for ; Mon, 6 Jan 2014 02:41:44 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id u57so15511357wes.18 for ; Mon, 06 Jan 2014 02:41:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=HO7gDKepFh5nA6RxluoO0U+q9p1OP7DzlrYI3y6XKgY=; b=EgMTHQfh3vrAHapDBwruNDq54/y2Nn5vADCFGBdf7vkCyHp4zv1WsBM0b/e818KpTU SLF51SuEGnM0ZWH8oX7cEu6oO/qpyt1zhS/Ju18maM5kcxosU5+v1C90hi/TIegdp6i0 2Tb5qpxTU34xMi9fENh+UjStrlTJdpP10RV5XtktoubeRXHVCqewi3Bi2pASs7dm1bwk nPnXI2dyK0c+rLVELX77FfgjSThAUghrZ+KLe0vRH4SOfN1oMBsy8i3wMhMVmYLzY5Ww ahJkASlfPcRQzI1vLt7Qnl4C31skn9Q+O4YatfUT2G1WBfbZOKBvfAQRUjZ08TzflS6J ZqbQ== X-Gm-Message-State: ALoCoQnyt9uQa+R9XbwyrLgh5m/qNZNy5orM3lCx0z+jXhAL5ezC0sqOVn6IKqm7EMSW0I05VKkP X-Received: by 10.180.77.72 with SMTP id q8mr11997421wiw.12.1389004896052; Mon, 06 Jan 2014 02:41:36 -0800 (PST) Received: from dhcp164-05.enst.fr (dhcp164-05.enst.fr. [137.194.165.5]) by mx.google.com with ESMTPSA id z2sm17207115wiy.11.2014.01.06.02.41.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jan 2014 02:41:34 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_AB370AEC-61EC-4AB9-ACA3-AF09FF7D0D6B" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: [tcmtf] TCMTF-Feedback about a possible BoF in London From: Luigi Iannone In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026EF2FF8F@MX15A.corp.emc.com> Date: Mon, 6 Jan 2014 11:41:32 +0100 Message-Id: <77C9FEE1-9EB2-4BE6-8D57-FF04F472EA57@gigix.net> References: <00c401cefd65$6e8ef570$4bace050$@unizar.es> <8D3D17ACE214DC429325B2B98F3AE712026EF2FF8F@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1827) Cc: "tcmtf@ietf.org" , Martin Stiemerling , "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 06 Jan 2014 10:41:47 -0000 --Apple-Mail=_AB370AEC-61EC-4AB9-ACA3-AF09FF7D0D6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi All, I agree with David that the charter is a bit prolix. IMHO it can be shortened in the following way: - Merge abd reduce paragraphs 2 and 3. I think that the main message = that the new paragraph should deliver is =93RFC4170 does not cover new = emerging scenarios=94, which will be completed by the current paragraph = 4. - Shorten paragraph 5. The charter should (IMHO) offer a list of sample = scenarios where bandwidth saving is desirable but the analysis of such = scenarios has to be done elsewhere. In the current form there is too = much details.=20 - Paragraph 6: I am not sure if we really need to keep such precise = figures in a charter. If people prefer to keep the text it should appear = earlier on in the charter (in the new second paragraph ???) to provide = motivation on using TCM solutions.=20 Having said that, I support the formation of the WG. ciao Luigi On 4 Jan. 2014, at 04:04 , Black, David wrote: > A second BoF has the explicit goal of forming a WG, as a third BoF > is not permitted. In that regard, the new charter seems long and > somewhat lacking in focus. Two key things I look for in a proposed > charter are what problem (or problems) the proposed WG is looking to > solve and an initial approach to the problem or problems. > =20 > In the new draft charter, the problem statement appears to be in > paragraph 4 with paragraph 1 providing important background. The > focus of the work appears to be on extending TCRTP (RFC 4170) to > UDP and to include new compression protocols. In contrast, I have > a hard time discerning the initial approach from the new draft = charter. > =20 > In light of this, there are a few things that I wish the new > draft charter had definitive proposals for: > =20 > a) Whether to replace RFC 4170 vs. write a new RFC (could be > UDP-only or UDP + RTP/UDP) as a complement to RFC 4170. > b) Whether to use ECRTP, ROHCv2 (RFC 5225) and/or IPHC (RFC 2507 = ?). > Non-use of ECRTP would be a major change to 4170, and I > wonder about IPHC, as opposed to the ROHCv2 profiles. > c) Analogies to b) for the Mux and Tunnel layers of the stack. > =20 > Overall, it looks like the first task of the WG is to select the = protocol > stack to standardize - I have misgivings about that, and would prefer = to > see a concrete proposal in a crisp charter that ran along the = following > lines, naming the protocols to be used: > =20 > 1) RFC 4170 does X, and needs the following changes/additions: X, Y, = Z. > 2) The WG will replace RFC 4170 with a new RFC that contains: A, B, C. > =20 > A specific proposal or proposals for the protocol stack or stacks > would also narrow the scope of item 9 in the charter on the = negotiation > mechanism. I also don=92t see a goal/milestone listed for an = extension to > or replacement for RFC 4170. > =20 > I=92d prefer to see a much shorter more focused draft charter. = There=92s a > bunch of background material that does not seem crucial to the = charter, > starting w/paragraphs 2 and 3. > =20 > Thanks, > --David > =20 > From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Jose = Saldana > Sent: Friday, December 20, 2013 4:26 AM > To: tcmtf@ietf.org; tsv-area@ietf.org > Cc: Martin Stiemerling > Subject: TCMTF-Feedback about a possible BoF in London > =20 > Hi all, > =20 > After the feedback received in the BoF in Berlin, we have updated the = TCM-TF charter and the two drafts. We have tried to solve all the = problems raised during the session. > =20 > Our plan is to request a new BoF in London next March, so we would = like to know your opinion about these two questions: > =20 > =20 > 1. Is the new, reduced scope of TCM-TF suitable to form a working = group? > =20 > =20 > 2. We would like to kindly ask people who think that a TCM-TF Working = group should be formed, to come forward and send an e-mail to the = tsv-area@ietf.org mailing list stating it. > =20 > =20 > This feedback will allow us to get a better idea of the convenience of = a BoF. > =20 > The new charter is here: = http://www.ietf.org/mail-archive/web/tcmtf/current/msg00465.html > This is the old one (presented in Berlin): = http://www.ietf.org/mail-archive/web/tcmtf/current/msg00368.html > =20 > In these links you can see the differences between the new versions of = the drafts and the old ones: > = http://tools.ietf.org/rfcdiff?url1=3Ddraft-saldana-tsvwg-tcmtf-06.txt&url2= =3Ddraft-saldana-tsvwg-tcmtf-05.txt > = http://tools.ietf.org/rfcdiff?url1=3Ddraft-suznjevic-tsvwg-mtd-tcmtf-02.tx= t&url2=3Ddraft-suznjevic-tsvwg-mtd-tcmtf-01.txt > =20 > =20 > The main improvements are: > =20 > - TCP optimization has been removed > - The classification of the scenarios has been refined and improved. = Some of them have been removed > - A section about energy consumption has been added to the main draft > - A reference to the potential problem of the MTU and packet loss has = been added > - The problem of the added delays is studied in detail in the second = draft > =20 > - The improvements of the charter are summarized here: = http://www.ietf.org/mail-archive/web/tcmtf/current/msg00466.html > =20 > =20 > Best regards, > =20 > Jose > =20 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf --Apple-Mail=_AB370AEC-61EC-4AB9-ACA3-AF09FF7D0D6B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = All,

I agree with David that the charter is a bit = prolix.

IMHO it can be shortened in the = following way:

- Merge abd reduce paragraphs 2 = and 3. I think that the main message that the new paragraph should = deliver is =93RFC4170 does not cover new emerging scenarios=94, which = will be completed by the current paragraph 4.

- = Shorten paragraph 5. The charter should (IMHO) offer a list of sample = scenarios where bandwidth saving is desirable but the analysis of such = scenarios has to be done elsewhere. In the current form there is too = much details. 

- Paragraph 6: I am not = sure if we really need to keep such precise figures in a charter. If = people prefer to keep the text it should appear earlier on in the = charter (in the new second paragraph ???) to provide motivation on using = TCM solutions. 

Having said that, I = support the formation of the = WG.

ciao

Luigi


On 4 Jan. 2014, at 04:04 , Black, David = <david.black@emc.com> = wrote:

A second BoF has = the explicit goal of forming a WG, as a third = BoF
is not = permitted.  In that regard, the new charter seems long = and
somewhat lacking = in focus.  Two key things I look for in a = proposed
charter are what = problem (or problems) the proposed WG is looking = to
solve and an = initial approach to the problem or problems.
 
In the new draft = charter, the problem statement appears to be = in
paragraph 4 with = paragraph 1 providing important background.  = The
focus of the work = appears to be on extending TCRTP (RFC 4170) = to
UDP and to = include new compression protocols.  In contrast, I = have
a hard time = discerning the initial approach from the new draft = charter.
 
In light of this, = there are a few things that I wish the new
draft charter had definitive proposals = for:
 
      a) Whether to replace RFC 4170 vs. = write a new RFC (could be
            = UDP-only or UDP + RTP/UDP) as a complement to RFC = 4170.
      b) Whether to use ECRTP, ROHCv2 = (RFC 5225) and/or IPHC (RFC 2507 ?).
            = Non-use of ECRTP would be a major change to 4170, and = I
wonder about IPHC, as opposed to the ROHCv2 = profiles.
      c) Analogies to b) for the Mux and = Tunnel layers of the stack.
 
Overall, it looks = like the first task of the WG is to select the = protocol
stack to = standardize - I have misgivings about that, and would prefer = to
see a concrete = proposal in a crisp charter that ran along the = following
lines, naming the = protocols to be used:
 
1) RFC 4170 does = X, and needs the following changes/additions: X, Y, = Z.
2) The WG will = replace RFC 4170 with a new RFC that contains: A, B, = C.
 
A specific = proposal or proposals for the protocol stack or = stacks
would also narrow = the scope of item 9 in the charter on the = negotiation
mechanism.  = I also don=92t see a goal/milestone listed for an extension = to
or replacement = for RFC 4170.
 
I=92d prefer to = see a much shorter more focused draft charter.  There=92s = a
bunch of = background material that does not seem crucial to the = charter,
starting = w/paragraphs 2 and 3.
 
Thanks,
--David
 
From: tsv-area [mailto:tsv-area-bounces@ietf.org= ] On Behalf = Of Jose = Saldana
Sent: Friday, December 20, 2013 = 4:26 AM
To: tcmtf@ietf.org; tsv-area@ietf.org
Cc: Martin = Stiemerling
Subject: TCMTF-Feedback about a = possible BoF in London
 
Hi all,
 
After the feedback = received in the BoF in Berlin, we have updated the TCM-TF charter and = the two drafts. We have tried to solve all the problems raised during = the session.
 
Our plan = is to request a new BoF in London next March, so we would like to know = your opinion about these two questions:
 
 
1. =  Is the new, reduced scope of TCM-TF suitable to form a working = group?
 
 
2. We = would like to kindly ask people who think that a TCM-TF Working group = should be formed, to come forward and send an e-mail to the tsv-area@ietf.org  mailing list stating = it.
 
 
This = feedback will allow us to get a better idea of the convenience of a = BoF.
 
This is the old one = (presented in Berlin): http://www.ietf.org/mail-archive/web/tcmtf/current/msg00368.ht= ml
 
In these = links you can see the differences between the new versions of the drafts = and the old ones:
 
 
The = main improvements are:
 
- TCP = optimization has been removed
- The = classification of the scenarios has been refined and improved. Some of = them have been removed
- A = section about energy consumption has been added to the main = draft
- A reference to the potential = problem of the MTU and packet loss has been added
- The problem of the added delays is studied in = detail in the second draft
 
- The = improvements of the charter are summarized here: http://www.ietf.org/mail-archive/web/tcmtf/current/msg00466.ht= ml
 
 
Best = regards,
 
Jose
 
__________________________= _____________________
tcmtf mailing list
tcmtf@ietf.org
https://www.ietf.org/= mailman/listinfo/tcmtf

= --Apple-Mail=_AB370AEC-61EC-4AB9-ACA3-AF09FF7D0D6B-- From jsaldana@unizar.es Wed Jan 8 03:22:50 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8E91AE2A1; Wed, 8 Jan 2014 03:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, ONE_TIME=0.714, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 xRDTlMV0sE7Z; Wed, 8 Jan 2014 03:22:46 -0800 (PST) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id A2F7A1AE18B; Wed, 8 Jan 2014 03:22:45 -0800 (PST) Received: from jsaldanapc ([195.76.232.154]) (authenticated bits=0) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s08BMPhi019651; Wed, 8 Jan 2014 12:22:27 +0100 From: "Jose Saldana" To: , Subject: Next version (v10) of TCM-TF charter draft Date: Wed, 8 Jan 2014 12:22:25 +0100 Message-ID: <001b01cf0c63$ea240b00$be6c2100$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01CF0C6C.4BECDFD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8MUTJEFfBaeFLER7ezjsW9Se+pLw== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: Martin Stiemerling X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jan 2014 11:22:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001C_01CF0C6C.4BECDFD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tunneling Compressed Multiplexed Traffic Flows (TCM-TF) charter draft v10 Description of Working Group 1. RFC4170 (TCRTP) defines a method for grouping packets when a number of UDP/RTP VoIP flows share a common path, considering three different layers: ECRTP header compression; PPPMux multiplexing; L2TPv3 tunneling. TCRTP optimizes the traffic, increasing the bandwidth efficiency of VoIP and reduces the amount of packets per second at the same time. 2. However, in the last years, emerging real-time services which use bare UDP instead of UDP/RTP have become popular. Due to the need of interactivity, many of these services use small packets (some tens of bytes). Some other services also send small packets, but they are not delay-sensitive (e.g., instant messaging, m2m packets in sensor networks). In addition, a significant effort has been devoted to the deployment of new header compression methods with improved robustness (ROHC). 3. So there is a need of replacing RFC4170 with an extended solution able to optimize these new flows, also using improved compression methods. The same structure of three layers will be considered: * Header compression: different protocols can be used: no compression, ECRTP, IPHC and ROHC. * Multiplexing: PPPMux will be the option. * Tunneling: the options in this layer are L2TP, GRE and MPLS. 4. New scenarios where bandwidth savings are desirable have been identified, in addition to those considered in RFC4170. In these scenarios, there are moments or places where network capacity gets scarce, so allocating more bandwidth is a possible solution, but it implies a recurring cost. However, the inclusion of a pair of boxes able to optimize the traffic when/where required is a one-time investment. These scenarios can be classified into: * Multidomain, the TCMT-TF tunnel goes all the way from one network edge to another, and can therefore cross several domains. * Single Domain, TCM-TF is only activated inside an ISP, from the edge to border inside the network operator. * Private Solutions. TCM-TF is used to connect private networks geographically apart (e.g. corporation headquarters and subsidiaries), without the ISP being aware or having to manage those flows. * Mixed Scenarios, any combination of the previous ones. 5. Since standard protocols are being used at each layer, the signaling methods of those protocols will be used. Thus, 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 would be obsoleted. 6. A first document (TCM-TF - reference model) will define the different options which can be used at each layer. It will include a detailed specification of the scenarios of interest. 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. The impact on other protocols will also be studied. 7. Taking into account that different options will be considered, when a pair of TCM-TF optimizers want to establish a session, they have first to negotiate which concrete option would they use in each layer. This will depend on the protocols that each extreme implements at each level, and in the scenario. So another document (TCM-TF - negotiation protocol) will include: * a mechanism to setup/release a TCM-TF session between an ingress and an egress-optimizer, also including: * a negotiation mechanism to decide the options to use at each layer . 8. As a counterpart of the bandwidth saving, TCM-TF 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 (TCM-TF - recommendations) with useful recommendations in order to decide which packet flows can or can not be multiplexed and how. The document 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. The eventual impact of multiplexing on protocol dynamics (e.g. the loss of a multiplexed packet, MTU-related issues) will also have to be addressed. 9. The working group may identify additional deliverables that are necessary/useful, e.g., a mechanism for a TCM-ingress optimizer to discover an egress optimizer, and vice versa. The working group would re-charter to add them before working on them. 10. Interactions with other Working Groups can be expected, since TCM-TF uses already defined protocols for compression, multiplexing and tunneling (ROHC, PPPMux, MPLS, GRE, L2TP). Goals and Milestones Specification of TCM-TF reference model and the scenarios of interest. This would obsolete RFC4170. Specification of TCM-TF negotiation protocol. Specification of TCM-TF recommendations of using existing traffic classification methods, maximum delay and jitter to add, depending on the service. Current version of Document (TCM-TF - reference model): https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/ Current version of Document (TCM-TF - recommendations): http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ ------=_NextPart_000_001C_01CF0C6C.4BECDFD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tunneling Compressed Multiplexed Traffic Flows (TCM-TF) = charter draft v10

 

Description of Working Group

 

1. RFC4170 (TCRTP) defines a method = for grouping packets when a number of UDP/RTP VoIP flows share a common = path, considering three different layers: ECRTP header compression; = PPPMux multiplexing; L2TPv3 tunneling. TCRTP optimizes the traffic, = increasing the bandwidth efficiency of VoIP and reduces the amount of = packets per second at the same time.

 

2. However, in the last years, = emerging real-time services which use bare UDP instead of UDP/RTP have = become popular. Due to the need of interactivity, many of these services = use small packets (some tens of bytes). Some other services also send = small packets, but they are not delay-sensitive (e.g., instant = messaging, m2m packets in sensor networks). In addition, a significant = effort has been devoted to the deployment of new header compression = methods with improved robustness (ROHC).

 

3. So there is a need of replacing = RFC4170 with an extended solution able to optimize these new flows, also = using improved compression methods. The same structure of three layers = will be considered:

 

* Header compression: different protocols can be used: no = compression, ECRTP, IPHC and ROHC.

* Multiplexing: PPPMux will be the = option.

* = Tunneling: the options in this layer are L2TP, GRE and = MPLS.

 

4. New scenarios where bandwidth savings are desirable have = been identified, in addition to those considered in RFC4170. In these = scenarios, there are moments or places where network capacity gets = scarce, so allocating more bandwidth is a possible solution, but it = implies a recurring cost. However, the inclusion of a pair of boxes able = to optimize the traffic when/where required is a one-time investment. = These scenarios can be classified into:

 

* Multidomain, the TCMT-TF tunnel = goes all the way from one network edge to another, and can therefore = cross several domains.

* Single Domain, TCM-TF is only activated inside an ISP, = from the edge to border inside the network operator. =

* Private = Solutions. TCM-TF is used to connect private networks geographically = apart (e.g. corporation headquarters and subsidiaries), without the ISP = being aware or having to manage those flows.

* Mixed Scenarios, any combination = of the previous ones.

 

5. Since standard protocols are being used at each layer, = the signaling methods of those protocols will be used. Thus, = 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 would be = obsoleted.

 

6. A first document (TCM-TF - reference model) will define = the different options which can be used at each layer. It will include a = detailed specification of the scenarios of interest. 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. The = impact on other protocols will also be studied.

 

7. Taking into account that = different options will be considered, when a pair of TCM-TF optimizers = want to establish a session, they have first to negotiate which concrete = option would they use in each layer. This will depend on the protocols = that each extreme implements at each level, and in the scenario. So = another document (TCM-TF - negotiation protocol) will = include:

 

* a mechanism to setup/release a TCM-TF session between an = ingress and an egress-optimizer, also including:

* a negotiation mechanism to decide = the options to use at each layer .

 

8. As a counterpart of the = bandwidth saving, TCM-TF 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 (TCM-TF - recommendations) with useful recommendations in = order to decide which packet flows can or can not be multiplexed and = how. The document 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. The eventual impact of = multiplexing on protocol dynamics (e.g. the loss of a multiplexed = packet, MTU-related issues) will also have to be = addressed.

 

9. The working group may identify additional deliverables = that are necessary/useful, e.g., a mechanism for a TCM-ingress optimizer = to discover an egress optimizer, and vice versa. The working group would = re-charter to add them before working on them.

 

10. Interactions with other Working = Groups can be expected, since TCM-TF uses already defined protocols for = compression, multiplexing and tunneling (ROHC, PPPMux, MPLS, GRE, L2TP). =

 

Goals and Milestones

 

Specification of TCM-TF reference = model and the scenarios of interest. This would obsolete = RFC4170.

 

Specification of TCM-TF negotiation = protocol.

 

Specification of TCM-TF recommendations of using existing = traffic classification methods, maximum delay and jitter to add, = depending on the service.

 

 

Current version of Document (TCM-TF = - reference model):

http= s://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/

 

Current version of Document (TCM-TF - = recommendations):

http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tc= mtf/

------=_NextPart_000_001C_01CF0C6C.4BECDFD0-- From jsaldana@unizar.es Wed Jan 8 03:23:59 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587771AE24D; Wed, 8 Jan 2014 03:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 UWEmN4Wu9bBe; Wed, 8 Jan 2014 03:23:57 -0800 (PST) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 456FB1AE190; Wed, 8 Jan 2014 03:23:57 -0800 (PST) Received: from jsaldanapc ([195.76.232.154]) (authenticated bits=0) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s08BNbsE004756; Wed, 8 Jan 2014 12:23:39 +0100 From: "Jose Saldana" To: , Subject: TCM-TF current drafts Date: Wed, 8 Jan 2014 12:23:35 +0100 Message-ID: <002001cf0c64$16febd50$44fc37f0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01CF0C6C.78C4ABF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8MUDMHI8WArDtQT76g60VDH0LMNw== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: Martin Stiemerling X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jan 2014 11:23:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0021_01CF0C6C.78C4ABF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, these are the current versions of the two drafts related to TCM-TF: Current version of Document (TCM-TF - reference model): https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/ Current version of Document (TCM-TF - recommendations): http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ Best regards, Jose ------=_NextPart_000_0021_01CF0C6C.78C4ABF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all, these are the current versions of the two drafts = related to TCM-TF:

 

Current version of Document (TCM-TF - reference = model):

http= s://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/

 

Current version of Document (TCM-TF - = recommendations):

http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

 

Best regards,

 

Jose

------=_NextPart_000_0021_01CF0C6C.78C4ABF0-- From david.black@emc.com Wed Jan 8 06:34:16 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B001AE3D8; Wed, 8 Jan 2014 06:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 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, ONE_TIME=0.714, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] 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 z9lijvikoFey; Wed, 8 Jan 2014 06:34:12 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 90F961AE3C1; Wed, 8 Jan 2014 06:34:00 -0800 (PST) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s08EXklQ029135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jan 2014 09:33:48 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s08EXklQ029135 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1389191628; bh=QIQsRoEUiSNSwTbHjPy+sLtfDNE=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=HlTm7k0ZBqINjkCiSrm6VMKBpb5bbHCihEqkToPnmIM6EC7AJfvFHn2Sm2RmrAqTL IBqZbZ5T6gGDPz+LiKMEPhdrX1lrK0xviXTZ2lclb/3xqQKUnlEDpNeeOs4Hhe8BOE dxfIAVUjEqYaDe3IB3EcL9MKy39RdIHgufTpR9Lk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s08EXklQ029135 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd54.lss.emc.com (RSA Interceptor); Wed, 8 Jan 2014 09:33:28 -0500 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s08EXR3c013868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jan 2014 09:33:28 -0500 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Wed, 8 Jan 2014 09:33:27 -0500 From: "Black, David" To: Jose Saldana , "tcmtf@ietf.org" , "tsv-area@ietf.org" Date: Wed, 8 Jan 2014 09:33:26 -0500 Subject: RE: Next version (v10) of TCM-TF charter draft Thread-Topic: Next version (v10) of TCM-TF charter draft Thread-Index: Ac8MUTJEFfBaeFLER7ezjsW9Se+pLwALH/ig Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026EF3043D@MX15A.corp.emc.com> References: <001b01cf0c63$ea240b00$be6c2100$@unizar.es> In-Reply-To: <001b01cf0c63$ea240b00$be6c2100$@unizar.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE712026EF3043DMX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: DLM_1, public Cc: Martin Stiemerling X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jan 2014 14:34:16 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE712026EF3043DMX15Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jose, This version is definitely improved. I would suggest moving the signaling material from paragraph 5 into paragra= ph 7 so that the existing signaling protocols and the new TCM-TF negotiatio= n protocol (including their intended relationship/interaction) are discusse= d in one place. The rest of paragraph 5 could then be merged into paragraph= 6. 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 ---------------------------------------------------- From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Jose Saldana Sent: Wednesday, January 08, 2014 6:22 AM To: tcmtf@ietf.org; tsv-area@ietf.org Cc: Martin Stiemerling Subject: Next version (v10) of TCM-TF charter draft Tunneling Compressed Multiplexed Traffic Flows (TCM-TF) charter draft v10 Description of Working Group 1. RFC4170 (TCRTP) defines a method for grouping packets when a number of U= DP/RTP VoIP flows share a common path, considering three different layers: = ECRTP header compression; PPPMux multiplexing; L2TPv3 tunneling. TCRTP opti= mizes the traffic, increasing the bandwidth efficiency of VoIP and reduces = the amount of packets per second at the same time. 2. However, in the last years, emerging real-time services which use bare U= DP instead of UDP/RTP have become popular. Due to the need of interactivity= , many of these services use small packets (some tens of bytes). Some other= services also send small packets, but they are not delay-sensitive (e.g., = instant messaging, m2m packets in sensor networks). In addition, a signific= ant effort has been devoted to the deployment of new header compression met= hods with improved robustness (ROHC). 3. So there is a need of replacing RFC4170 with an extended solution able t= o optimize these new flows, also using improved compression methods. The sa= me structure of three layers will be considered: * Header compression: different protocols can be used: no compression, ECRT= P, IPHC and ROHC. * Multiplexing: PPPMux will be the option. * Tunneling: the options in this layer are L2TP, GRE and MPLS. 4. New scenarios where bandwidth savings are desirable have been identified= , in addition to those considered in RFC4170. In these scenarios, there are= moments or places where network capacity gets scarce, so allocating more b= andwidth is a possible solution, but it implies a recurring cost. However, = the inclusion of a pair of boxes able to optimize the traffic when/where re= quired is a one-time investment. These scenarios can be classified into: * Multidomain, the TCMT-TF tunnel goes all the way from one network edge to= another, and can therefore cross several domains. * Single Domain, TCM-TF is only activated inside an ISP, from the edge to b= order inside the network operator. * Private Solutions. TCM-TF is used to connect private networks geographica= lly apart (e.g. corporation headquarters and subsidiaries), without the ISP= being aware or having to manage those flows. * Mixed Scenarios, any combination of the previous ones. 5. Since standard protocols are being used at each layer, the signaling met= hods of those protocols will be used. Thus, interactions with the Working G= roups and Areas in which these protocols are developed can be expected. How= ever, the development of new compressing, multiplexing or tunneling protoco= ls is not an objective of this Working Group. In addition, since the curren= t RFC 4170 would be considered as one of the options, this RFC would be obs= oleted. 6. A first document (TCM-TF - reference model) will define the different op= tions which can be used at each layer. It will include a detailed specifica= tion of the scenarios of interest. Specific problems caused by the interact= ion between layers will have to be issued, and suitable extensions may have= to be added to the involved protocols. The impact on other protocols will = also be studied. 7. Taking into account that different options will be considered, when a pa= ir of TCM-TF optimizers want to establish a session, they have first to neg= otiate which concrete option would they use in each layer. This will depend= on the protocols that each extreme implements at each level, and in the sc= enario. So another document (TCM-TF - negotiation protocol) will include: * a mechanism to setup/release a TCM-TF session between an ingress and an e= gress-optimizer, also including: * a negotiation mechanism to decide the options to use at each layer . 8. As a counterpart of the bandwidth saving, TCM-TF may add some delay and = jitter. This is not a problem for the services which are not sensitive to d= elay. However, regarding delay-sensitive services, the Working Group will a= lso develop a document (TCM-TF - recommendations) with useful recommendatio= ns in order to decide which packet flows can or can not be multiplexed and = how. The document will present a list of available traffic classification m= ethods which can be used for identification of the service or application t= o which a particular flow belongs, as well as recommendations of the maximu= m delay and jitter to be added depending of the identified service or appli= cation. The eventual impact of multiplexing on protocol dynamics (e.g. the = loss of a multiplexed packet, MTU-related issues) will also have to be addr= essed. 9. The working group may identify additional deliverables that are necessar= y/useful, e.g., a mechanism for a TCM-ingress optimizer to discover an egre= ss optimizer, and vice versa. The working group would re-charter to add the= m before working on them. 10. Interactions with other Working Groups can be expected, since TCM-TF us= es already defined protocols for compression, multiplexing and tunneling (R= OHC, PPPMux, MPLS, GRE, L2TP). Goals and Milestones Specification of TCM-TF reference model and the scenarios of interest. This= would obsolete RFC4170. Specification of TCM-TF negotiation protocol. Specification of TCM-TF recommendations of using existing traffic classific= ation methods, maximum delay and jitter to add, depending on the service. Current version of Document (TCM-TF - reference model): https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/ Current version of Document (TCM-TF - recommendations): http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ --_000_8D3D17ACE214DC429325B2B98F3AE712026EF3043DMX15Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jose,

 

This v= ersion is definitely improved.

&= nbsp;

I would suggest moving the signaling= material from paragraph 5 into paragraph 7 so that the existing signaling = protocols and the new TCM-TF negotiation protocol (including their intended= relationship/interaction) are discussed in one place. The rest of paragrap= h 5 could then be merged into paragraph 6.

 

Thanks,
--David<= br>----------------------------------------------------
David L. Black, = Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA&nbs= p; 01748
+1 (508) 293-7953       &nbs= p;     FAX: +1 (508) 293-7786
david.black@emc.com&nb= sp;       Mobile: +1 (978) 394-7754
------= ----------------------------------------------

= From:= tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Jose Salda= na
Sent: Wednesday, January 08, 2014 6:22 AM
To: tcmtf@= ietf.org; tsv-area@ietf.org
Cc: Martin Stiemerling
Subject:= Next version (v10) of TCM-TF charter draft

=

 

Tunnel= ing Compressed Multiplexed Traffic Flows (TCM-TF) charter draft v10

 

Descr= iption of Working Group

 

1. RFC4170 (TCRTP) defines a method for grouping = packets when a number of UDP/RTP VoIP flows share a common path, considerin= g three different layers: ECRTP header compression; PPPMux multiplexing; L2= TPv3 tunneling. TCRTP optimizes the traffic, increasing the bandwidth effic= iency of VoIP and reduces the amount of packets per second at the same time= .

 

2. However, in the last years, emerging real-time services which use ba= re UDP instead of UDP/RTP have become popular. Due to the need of interacti= vity, many of these services use small packets (some tens of bytes). Some o= ther services also send small packets, but they are not delay-sensitive (e.= g., instant messaging, m2m packets in sensor networks). In addition, a sign= ificant effort has been devoted to the deployment of new header compression= methods with improved robustness (ROHC).

 

3. So there is a need of replac= ing RFC4170 with an extended solution able to optimize these new flows, als= o using improved compression methods. The same structure of three layers wi= ll be considered:

 

<= p class=3DMsoNormal>* Header compression: different protocols can be used: = no compression, ECRTP, IPHC and ROHC.

* = Multiplexing: PPPMux will be the option.

* Tunneling: the options in this layer are L2TP, GRE and MPLS.<= /p>

 

4. New sc= enarios where bandwidth savings are desirable have been identified, in addi= tion to those considered in RFC4170. In these scenarios, there are moments = or places where network capacity gets scarce, so allocating more bandwidth = is a possible solution, but it implies a recurring cost. However, the inclu= sion of a pair of boxes able to optimize the traffic when/where required is= a one-time investment. These scenarios can be classified into:<= /p>

 

* Multido= main, the TCMT-TF tunnel goes all the way from one network edge to another,= and can therefore cross several domains.

* Single Domain, TCM-TF is only activated inside an ISP, from the edge to= border inside the network operator.

* = Private Solutions. TCM-TF is used to connect private networks geographicall= y apart (e.g. corporation headquarters and subsidiaries), without the ISP b= eing aware or having to manage those flows.

* Mixed Scenarios, any combination of the previous ones.

=

 

5. Since sta= ndard protocols are being used at each layer, the signaling methods of thos= e protocols will be used. Thus, interactions with the Working Groups and Ar= eas in which these protocols are developed can be expected. However, the de= velopment of new compressing, multiplexing or tunneling protocols is not an= objective of this Working Group. In addition, since the current RFC 4170 w= ould be considered as one of the options, this RFC would be obsoleted.=

 

6.= A first document (TCM-TF - reference model) will define the different opti= ons which can be used at each layer. It will include a detailed specificati= on of the scenarios of interest. Specific problems caused by the interactio= n between layers will have to be issued, and suitable extensions may have t= o be added to the involved protocols. The impact on other protocols will al= so be studied.

 

7. Taking into account that different options will be cons= idered, when a pair of TCM-TF optimizers want to establish a session, they = have first to negotiate which concrete option would they use in each layer.= This will depend on the protocols that each extreme implements at each lev= el, and in the scenario. So another document (TCM-TF - negotiation protocol= ) will include:

 

* a mechanism to setup/release a TCM-TF session between a= n ingress and an egress-optimizer, also including:

* a negotiation mechanism to decide the options to use at each= layer .

 

8. As a counterpart of the bandwidth saving, TCM-TF may add so= me delay and jitter. This is not a problem for the services which are not s= ensitive to delay. However, regarding delay-sensitive services, the Working= Group will also develop a document (TCM-TF - recommendations) with useful = recommendations in order to decide which packet flows can or can not be mul= tiplexed and how. The document will present a list of available traffic cla= ssification 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 ser= vice or application. The eventual impact of multiplexing on protocol dynami= cs (e.g. the loss of a multiplexed packet, MTU-related issues) will also ha= ve to be addressed.

 

9. The working group may identify additional delivera= bles that are necessary/useful, e.g., a mechanism for a TCM-ingress optimiz= er to discover an egress optimizer, and vice versa. The working group would= re-charter to add them before working on them.

 

10. Interactions with oth= er Working Groups can be expected, since TCM-TF uses already defined protoc= ols for compression, multiplexing and tunneling (ROHC, PPPMux, MPLS, GRE, L= 2TP).

 

Goals and Milestones

 = ;

Specification of TCM-TF reference model and= the scenarios of interest. This would obsolete RFC4170.

 

Specification of= TCM-TF negotiation protocol.

 = ;

Specification of TCM-TF recommendations of = using existing traffic classification methods, maximum delay and jitter to = add, depending on the service.

&nbs= p;

 

= Current version of Document (TCM-TF - reference model):

https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/

 

Current version of Document (TCM-TF - recommendations):

<= p class=3DMsoNormal>http://datatracker= .ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/=

= --_000_8D3D17ACE214DC429325B2B98F3AE712026EF3043DMX15Acorpemcc_-- From jsaldana@unizar.es Wed Jan 8 16:11:53 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B81F1ACCEC; Wed, 8 Jan 2014 16:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 HE97BzjnAT92; Wed, 8 Jan 2014 16:11:48 -0800 (PST) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1C91ADEA7; Wed, 8 Jan 2014 16:11:41 -0800 (PST) Received: from jsaldanapc ([107.19.188.169]) (authenticated bits=0) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s090B1fQ014219; Thu, 9 Jan 2014 01:11:08 +0100 From: "Jose Saldana" To: "'Black, David'" , , , "Luigi Iannone" References: <00c401cefd65$6e8ef570$4bace050$@unizar.es> <8D3D17ACE214DC429325B2B98F3AE712026EF2FF8F@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026EF2FF8F@MX15A.corp.emc.com> Subject: RE: TCMTF-Feedback about a possible BoF in London Date: Thu, 9 Jan 2014 01:10:48 +0100 Message-ID: <004701cf0ccf$4d5826a0$e80873e0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0048_01CF0CD7.AF212280" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKm4iuy1T4jUNWcvPCI8e0mPkHF7QHB3wddmLzCScA= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: 'Martin Stiemerling' X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jan 2014 00:11:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0048_01CF0CD7.AF212280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all. =20 First of all, thanks to David and Luigi for their valuable comments. =20 I will wait for a while in order to include David=92s comments (perhaps = some other people has more suggestions). =20 These are the improvements of version 10 with respect to v9 ( http://www.ietf.org/mail-archive/web/tcmtf/current/msg00486.html) =20 - I have shortened paragraph 1. - I have shortened and merged paragraphs 2 and 3. - I have moved paragraph 4 to the third place, in order to set clearer = what we want: replacing RFC4170 with a widened proposal. As David suggested, = I have also shortened the text and it is now more straightforward. - I have clearly stated which protocols will be used on each layer. The negotiation mechanism is still necessary, since different options are considered e.g. for header compression. The one to be used will depend = on the scenario and the processing capacity of the two optimizers. - I have significantly shortened the description of the scenarios. - I have removed paragraph 6, which included the savings figures. - I have included the replacement of RFC4170 in the first milestone. =20 Thanks! =20 Jose =20 De: Black, David [ = mailto:david.black@emc.com]=20 Enviado el: s=E1bado, 04 de enero de 2014 4:05 Para: Jose Saldana; tcmtf@ietf.org; tsv-area@ietf.org CC: Martin Stiemerling; Black, David Asunto: RE: TCMTF-Feedback about a possible BoF in London =20 A second BoF has the explicit goal of forming a WG, as a third BoF is not permitted. In that regard, the new charter seems long and somewhat lacking in focus. Two key things I look for in a proposed charter are what problem (or problems) the proposed WG is looking to solve and an initial approach to the problem or problems. =20 In the new draft charter, the problem statement appears to be in paragraph 4 with paragraph 1 providing important background. The focus of the work appears to be on extending TCRTP (RFC 4170) to UDP and to include new compression protocols. In contrast, I have a hard time discerning the initial approach from the new draft charter. =20 In light of this, there are a few things that I wish the new draft charter had definitive proposals for: =20 a) Whether to replace RFC 4170 vs. write a new RFC (could be UDP-only or UDP + RTP/UDP) as a complement to RFC 4170. b) Whether to use ECRTP, ROHCv2 (RFC 5225) and/or IPHC (RFC 2507 = ?). Non-use of ECRTP would be a major change to 4170, and I wonder about IPHC, as opposed to the ROHCv2 profiles. c) Analogies to b) for the Mux and Tunnel layers of the stack. =20 Overall, it looks like the first task of the WG is to select the = protocol stack to standardize - I have misgivings about that, and would prefer to see a concrete proposal in a crisp charter that ran along the following lines, naming the protocols to be used: =20 1) RFC 4170 does X, and needs the following changes/additions: X, Y, Z. 2) The WG will replace RFC 4170 with a new RFC that contains: A, B, C. =20 A specific proposal or proposals for the protocol stack or stacks would also narrow the scope of item 9 in the charter on the negotiation mechanism. I also don=92t see a goal/milestone listed for an extension = to or replacement for RFC 4170. =20 I=92d prefer to see a much shorter more focused draft charter. = There=92s a bunch of background material that does not seem crucial to the charter, starting w/paragraphs 2 and 3. =20 Thanks, --David =20 From: tsv-area [ mailto:tsv-area-bounces@ietf.org] On Behalf Of Jose Saldana Sent: Friday, December 20, 2013 4:26 AM To: tcmtf@ietf.org; tsv-area@ietf.org Cc: Martin Stiemerling Subject: TCMTF-Feedback about a possible BoF in London =20 Hi all, =20 After the feedback received in the BoF in Berlin, we have updated the = TCM-TF charter and the two drafts. We have tried to solve all the problems = raised during the session. =20 Our plan is to request a new BoF in London next March, so we would like = to know your opinion about these two questions: =20 =20 1. Is the new, reduced scope of TCM-TF suitable to form a working = group? =20 =20 2. We would like to kindly ask people who think that a TCM-TF Working = group should be formed, to come forward and send an e-mail to the tsv-area@ietf.org mailing list stating it. =20 =20 This feedback will allow us to get a better idea of the convenience of a BoF. =20 The new charter is here: http://www.ietf.org/mail-archive/web/tcmtf/current/msg00465.html This is the old one (presented in Berlin): http://www.ietf.org/mail-archive/web/tcmtf/current/msg00368.html =20 In these links you can see the differences between the new versions of = the drafts and the old ones: =20 http://tools.ietf.org/rfcdiff?url1=3Ddraft-saldana-tsvwg-tcmtf-06.txt&url= 2=3Ddra ft-saldana-tsvwg-tcmtf-05.txt =20 http://tools.ietf.org/rfcdiff?url1=3Ddraft-suznjevic-tsvwg-mtd-tcmtf-02.t= xt&ur l2=3Ddraft-suznjevic-tsvwg-mtd-tcmtf-01.txt =20 =20 The main improvements are: =20 - TCP optimization has been removed - The classification of the scenarios has been refined and improved. = Some of them have been removed - A section about energy consumption has been added to the main draft - A reference to the potential problem of the MTU and packet loss has = been added - The problem of the added delays is studied in detail in the second = draft =20 - The improvements of the charter are summarized here: http://www.ietf.org/mail-archive/web/tcmtf/current/msg00466.html =20 =20 Best regards, =20 Jose =20 ------=_NextPart_000_0048_01CF0CD7.AF212280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all.

 

First of = all, thanks to David and Luigi for their valuable = comments.

 

I will wait = for a while in order to include David’s comments (perhaps some = other people has more suggestions).

 

These are = the improvements of version 10 with respect to v9 (http://www.ietf.org/mail-archive/web/tcmtf/current/msg00486.= html)

 

- I have = shortened paragraph 1.

- I have shortened and merged = paragraphs 2 and 3.

- I have moved paragraph 4 to the = third place, in order to set clearer what we want: replacing RFC4170 = with a widened proposal. As David suggested, I have also shortened the = text and it is now more straightforward.

- I have = clearly stated which protocols will be used on each layer. The = negotiation mechanism is still necessary, since different options are = considered e.g. for header compression. The one to be used will depend = on the scenario and the processing capacity of the two = optimizers.

- I have significantly shortened the description = of the scenarios.

- I have removed paragraph 6, which = included the savings figures.

- I have = included the replacement of RFC4170 in the first = milestone.

 

Thanks!

 

Jose

 

De: Black, = David [mailto:david.black@emc.com] =
Enviado el: s=E1bado, 04 de enero de 2014 = 4:05
Para: Jose Saldana; tcmtf@ietf.org; = tsv-area@ietf.org
CC: Martin Stiemerling; Black, David
Asunto: RE: TCMTF-Feedback = about a possible BoF in London

 

A = second BoF has the explicit goal of forming a WG, as a third = BoF

is not = permitted.  In that regard, the new charter seems long = and

somewhat lacking in focus.  Two key things I look = for in a proposed

charter are what problem (or problems) the proposed WG = is looking to

solve and an initial approach to the problem or = problems.

 

In the new draft charter, the problem statement = appears to be in

paragraph 4 with paragraph 1 providing important = background.  The

focus of the work appears to be on extending TCRTP = (RFC 4170) to

UDP and to include new compression protocols.  In = contrast, I have

a hard time discerning the initial approach from the = new draft charter.

 

In light of this, there are a few things that I wish = the new

draft = charter had definitive proposals for:

 

      a) Whether to replace = RFC 4170 vs. write a new RFC (could be

         &= nbsp;  UDP-only or UDP + RTP/UDP) as a complement to RFC = 4170.

      b) Whether to use = ECRTP, ROHCv2 (RFC 5225) and/or IPHC (RFC 2507 = ?).

         &= nbsp;  Non-use of ECRTP would be a major change to 4170, and = I

wonder = about IPHC, as opposed to the ROHCv2 profiles.

      c) Analogies to b) for = the Mux and Tunnel layers of the stack.

 

Overall, it looks like the first task of the WG is to = select the protocol

stack to standardize - I have misgivings about that, = and would prefer to

see a concrete proposal in a crisp charter that ran = along the following

lines, naming the protocols to be = used:

 

1) RFC 4170 does X, and needs the following = changes/additions: X, Y, Z.

2) The = WG will replace RFC 4170 with a new RFC that contains: A, B, = C.

 

A specific proposal or proposals for the protocol = stack or stacks

would also narrow the scope of item 9 in the charter = on the negotiation

mechanism.  I also don’t see a = goal/milestone listed for an extension to

or = replacement for RFC 4170.

 

I’d prefer to see a much shorter more focused = draft charter.  There’s a

bunch = of background material that does not seem crucial to the = charter,

starting w/paragraphs 2 and 3.

 

Thanks,
--David

 

From:= tsv-area = [mailto:tsv-a= rea-bounces@ietf.org] On = Behalf Of Jose Saldana
Sent: Friday, December 20, 2013 = 4:26 AM
To: tcmtf@ietf.o= rg; tsv-area@iet= f.org
Cc: Martin Stiemerling
Subject: TCMTF-Feedback about a possible = BoF in London

 

Hi all,

 

After the feedback received in the = BoF in Berlin, we have updated the TCM-TF charter and the two drafts. We = have tried to solve all the problems raised during the = session.

 

Our plan is to request a new BoF in London next March, so = we would like to know your opinion about these two = questions:

 

 

1.  Is the new, reduced scope of TCM-TF suitable to = form a working group?

 

 

2. We would like to kindly ask people who think that a = TCM-TF Working group should be formed, to come forward and send an = e-mail to the tsv-area@ietf.org =  mailing list stating it.

 

 

This feedback will allow us to get = a better idea of the convenience of a BoF.

 

The new charter is here: http://www.ietf.org/mail-archive/web/tcmtf/current/msg00465.= html

This is the old one (presented in = Berlin): http://www.ietf.org/mail-archive/web/tcmtf/current/msg00368.= html

 

In these links you can see the = differences between the new versions of the drafts and the old = ones:

http://tools.ietf.org/rfcdiff?url1=3Ddraft-saldana-tsvwg-tcm= tf-06.txt&url2=3Ddraft-saldana-tsvwg-tcmtf-05.txt

http://tools.ietf.org/rfcdiff?url1=3Ddraft-suznjevic-tsvwg-m= td-tcmtf-02.txt&url2=3Ddraft-suznjevic-tsvwg-mtd-tcmtf-01.txt<= /a>

 

 

The main improvements are:

 

- TCP optimization has been = removed

- = The classification of the scenarios has been refined and improved. Some = of them have been removed

- A section about energy = consumption has been added to the main draft

- A reference to the potential = problem of the MTU and packet loss has been = added

- The = problem of the added delays is studied in detail in the second = draft

 

- The improvements of the charter are summarized here: = http://www.ietf.org/mail-archive/web/tcmtf/current/msg00466.= html

 

 

Best = regards,

 

Jose

 

------=_NextPart_000_0048_01CF0CD7.AF212280-- From fpb@tid.es Thu Jan 9 09:50:26 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BB31AE2B9; Thu, 9 Jan 2014 09:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.025 X-Spam-Level: X-Spam-Status: No, score=-4.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, ONE_TIME=0.714, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 iUK2WIdAV5gc; Thu, 9 Jan 2014 09:50:19 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 869471ADF6D; Thu, 9 Jan 2014 09:50:15 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MZ500HNEAVCXV@tid.hi.inet>; Thu, 09 Jan 2014 18:50:00 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id AD.2F.02810.841EEC25; Thu, 09 Jan 2014 18:50:00 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MZ500HMYAVBXV@tid.hi.inet>; Thu, 09 Jan 2014 18:50:00 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.204]) by EX10-HTCAS7-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Thu, 09 Jan 2014 18:49:59 +0100 Date: Thu, 09 Jan 2014 17:49:59 +0000 From: FERNANDO PASCUAL BLANCO Subject: Re: [tcmtf] TCMTF-Feedback about a possible BoF in London In-reply-to: X-Originating-IP: [10.95.64.115] To: Jose Saldana Message-id: <19613893-ECE3-4CB5-A159-4E9D61788408@tid.es> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_g8g+2DCVqy5h+Mk75LOgvw)" Content-language: en-US Accept-Language: en-US, es-ES Thread-topic: [tcmtf] TCMTF-Feedback about a possible BoF in London Thread-index: Ac79ZUO9+o1eWvDOTZW4bKGOX0YCWwLjYMDQAPUFvwAAAVukgAAjn8+A X-AuditID: 0a5f4e69-b7f9b8e000000afa-e0-52cee148b833 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsXCFe9nqOvx8FyQwbbvvBa7Pm9gtFjwZjGz A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyVix8yF7w7xFTxbs7QQ2M63cwdTFycEgImEg865To YuQEMsUkLtxbzwZiCwlsY5R4eFMAwn7KKLFlh1EXIxeQPZNRovf4dSaQBIuAqsSk5Q+ZQWw2 AS2J03dXsYDYwgJOEsseP2ABmc8pYCfxb0YpxHwFiT/nHoOViAC1Lj37mwlkJrPAR0aJ/rPX GUESvAKWErt2vWGCsAUlfky+B9bALBAtcWX6NChbXKK59SaYzSggK/Fu/nxWiKHOEicPvmEG 2Ssi4CZx/rc5xF4BiSV7zjND2KISLx//Y4X45TajxO7p75knMIrNQrJuFpJ1s5Csg7ANJN6f m88MYWtLLFv4GsrWl9j45SwjhG0msa1zB4qaBYwcqxjFipOKMtMzSnITM3PSDYz0MjL1MvNS SzYxQuIycwfj8p0qhxgFOBiVeHhXFJ8NEmJNLCuuzD3EKMHBrCTCu+biuSAh3pTEyqrUovz4 otKc1OJDjEwcnFINjHZek58LnHU+pClq+C/6+JbA8m+vzGaKKTXMWVB3pVzPqdC1+PRUPi6x v/+1V4TsPrYnwWNJjcu7AM4nh2RXz/Vu/8C+gsnrkkTkwqQvt+Ovx+m+DG8s1gm5/71Q0P/W b+Xmjw3VfxYmeUzb42QT9fu9+THp36ue3a0QnHOdd0LSlBdJhxcIVyixFGckGmoxFxUnAgC/ rr2uqQIAAA== References: <00c401cefd65$6e8ef570$4bace050$@unizar.es> <8D3D17ACE214DC429325B2B98F3AE712026EF2FF8F@MX15A.corp.emc.com> <004701cf0ccf$4d5826a0$e80873e0$@unizar.es> Cc: "tcmtf@ietf.org" , "tsv-area@ietf.org" , Martin Stiemerling X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jan 2014 17:50:26 -0000 --Boundary_(ID_g8g+2DCVqy5h+Mk75LOgvw) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Hi all, Just to say that I also completely support the creation of the WG. There is= no doubt that network protocols have evolved, and not always as we thought= , and TCRTP needs to be wider. Regards, Fernando On 09/01/2014, at 01:49, Tina TSOU > wrote: Dear all, I'm in favor of having a BoF in London, as the following problem statement = seems valid and needs protocol work in IETF. --- In addition to VoIP, in the last years we are witnessing the raise of new r= eal-time services e.g. videoconferencing, telemedicine, video vigilance, on= line 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 between the = extremes of the communication. Their small data payloads incur significant = overhead, and it becomes even higher when IPv6 is used, since the basic IPv= 6 header is twice the size of the IPv4 one. In the moments or places where network capacity gets scarce, allocating mor= e bandwidth is a possible solution, but it implies a recurring cost. Howeve= r, the inclusion of a pair of boxes able to optimize the traffic (reducing = bandwidth and packets per second) when/where required is a one-time investm= ent. We can do these three things: a) header compression algorithms (e.g. ROHC) can be used for reducing the o= verhead of each flow; b) at the same time, tunneling can be used in order to allow the header-com= pressed packets to travel end-to-end c) compressed packets belonging to different flows can be multiplexed toget= her, in order to share the tunnel overhead. These emerging real-time services which use bare UDP instead of UDP/RTP hav= e become popular. In addition, a significant effort has been devoted to the= deployment of new header compression methods with improved robustness (ROH= C). So there is a need of widening the scope of RFC4170 in order to conside= r these new header compression methods, and also UDP in addition to UDP/RTP= . As a result, the next objectives can be achieved: * Significant bandwidth reductions (as an example, bandwidth savings of 55%= can be obtained for VoIP if IPv4 is used, and 65% using IPv6. For certain = online games, 33% of the bandwidth can be saved for IPv4, and 55% when usin= g IPv6). * A reduction of the amount of packets per second managed by the network. A= reduction factor of 10 or 20 can easily be achieved. This can be translate= d into smaller processing delays and energy savings in intermediate routers= . --- Thank you, Tina On Jan 8, 2014, at 4:11 PM, "Jose Saldana" > wrote: Hi all. First of all, thanks to David and Luigi for their valuable comments. I will wait for a while in order to include David=92s comments (perhaps som= e other people has more suggestions). These are the improvements of version 10 with respect to v9 (http://www.iet= f.org/mail-archive/web/tcmtf/current/msg00486.html) - I have shortened paragraph 1. - I have shortened and merged paragraphs 2 and 3. - I have moved paragraph 4 to the third place, in order to set clearer what= we want: replacing RFC4170 with a widened proposal. As David suggested, I = have also shortened the text and it is now more straightforward. - I have clearly stated which protocols will be used on each layer. The neg= otiation mechanism is still necessary, since different options are consider= ed e.g. for header compression. The one to be used will depend on the scena= rio and the processing capacity of the two optimizers. - I have significantly shortened the description of the scenarios. - I have removed paragraph 6, which included the savings figures. - I have included the replacement of RFC4170 in the first milestone. Thanks! Jose De: Black, David [mailto:david.black@emc.com] Enviado el: s=E1bado, 04 de enero de 2014 4:05 Para: Jose Saldana; tcmtf@ietf.org; tsv-area@ietf.or= g CC: Martin Stiemerling; Black, David Asunto: RE: TCMTF-Feedback about a possible BoF in London A second BoF has the explicit goal of forming a WG, as a third BoF is not permitted. In that regard, the new charter seems long and somewhat lacking in focus. Two key things I look for in a proposed charter are what problem (or problems) the proposed WG is looking to solve and an initial approach to the problem or problems. In the new draft charter, the problem statement appears to be in paragraph 4 with paragraph 1 providing important background. The focus of the work appears to be on extending TCRTP (RFC 4170) to UDP and to include new compression protocols. In contrast, I have a hard time discerning the initial approach from the new draft charter. In light of this, there are a few things that I wish the new draft charter had definitive proposals for: a) Whether to replace RFC 4170 vs. write a new RFC (could be UDP-only or UDP + RTP/UDP) as a complement to RFC 4170. b) Whether to use ECRTP, ROHCv2 (RFC 5225) and/or IPHC (RFC 2507 ?). Non-use of ECRTP would be a major change to 4170, and I wonder about IPHC, as opposed to the ROHCv2 profiles. c) Analogies to b) for the Mux and Tunnel layers of the stack. Overall, it looks like the first task of the WG is to select the protocol stack to standardize - I have misgivings about that, and would prefer to see a concrete proposal in a crisp charter that ran along the following lines, naming the protocols to be used: 1) RFC 4170 does X, and needs the following changes/additions: X, Y, Z. 2) The WG will replace RFC 4170 with a new RFC that contains: A, B, C. A specific proposal or proposals for the protocol stack or stacks would also narrow the scope of item 9 in the charter on the negotiation mechanism. I also don=92t see a goal/milestone listed for an extension to or replacement for RFC 4170. I=92d prefer to see a much shorter more focused draft charter. There=92s a bunch of background material that does not seem crucial to the charter, starting w/paragraphs 2 and 3. Thanks, --David From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Jose Saldana Sent: Friday, December 20, 2013 4:26 AM To: tcmtf@ietf.org; tsv-area@ietf.org Cc: Martin Stiemerling Subject: TCMTF-Feedback about a possible BoF in London Hi all, After the feedback received in the BoF in Berlin, we have updated the TCM-T= F charter and the two drafts. We have tried to solve all the problems raise= d during the session. Our plan is to request a new BoF in London next March, so we would like to = know your opinion about these two questions: 1. Is the new, reduced scope of TCM-TF suitable to form a working group? 2. We would like to kindly ask people who think that a TCM-TF Working group= should be formed, to come forward and send an e-mail to the tsv-area@ietf.= org mailing list stating it. This feedback will allow us to get a better idea of the convenience of a Bo= F. The new charter is here: http://www.ietf.org/mail-archive/web/tcmtf/current= /msg00465.html This is the old one (presented in Berlin): http://www.ietf.org/mail-archive= /web/tcmtf/current/msg00368.html In these links you can see the differences between the new versions of the = drafts and the old ones: http://tools.ietf.org/rfcdiff?url1=3Ddraft-saldana-tsvwg-tcmtf-06.txt&url2= =3Ddraft-saldana-tsvwg-tcmtf-05.txt http://tools.ietf.org/rfcdiff?url1=3Ddraft-suznjevic-tsvwg-mtd-tcmtf-02.txt= &url2=3Ddraft-suznjevic-tsvwg-mtd-tcmtf-01.txt The main improvements are: - TCP optimization has been removed - The classification of the scenarios has been refined and improved. Some o= f them have been removed - A section about energy consumption has been added to the main draft - A reference to the potential problem of the MTU and packet loss has been = added - The problem of the added delays is studied in detail in the second draft - The improvements of the charter are summarized here: http://www.ietf.org/= mail-archive/web/tcmtf/current/msg00466.html Best regards, Jose _______________________________________________ tcmtf mailing list tcmtf@ietf.org https://www.ietf.org/mailman/listinfo/tcmtf ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_g8g+2DCVqy5h+Mk75LOgvw) Content-id: Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable Hi all,

Just t= o say that I also completely support the creation of the WG. There is no do= ubt that network protocols have evolved, and not always as we thought, and = TCRTP needs to be wider.

Regards,
Fernando


On 09/01/2014, at 01:49, Tina TSOU <Tina.Tsou.Zouting@huawei.com> wrote:

Dear all,
I'm in favor of having a BoF in London, as the following problem state= ment seems valid and needs protocol work in IETF.
---
In addition to VoIP, in the last years we are witnessing the raise o= f new real-time services e.g. videoconferencing, telemedicine, video vigila= nce, online gaming, etc.

 

Due to the need of interactivity, many of these services use small p= ackets (some tens of bytes), since they have to send frequent updates between the extremes of the communication. Their small da= ta payloads incur significant overhead, and it becomes even higher when IPv= 6 is used, since the basic IPv6 header is twice the size of the IPv4 one.

 

In the moments or places where network capacity gets scarce, allocat= ing more bandwidth is a possible solution, but it implies a recurring cost.= However, the inclusion of a pair of boxes able to optimize the traffic (reducing bandwidth and packets per second) w= hen/where required is a one-time investment. We can do these three things:<= /font>

 

a) header compression algorithms (e.g. ROHC) can be used for reducin= g the overhead of each flow;
b) at the same time, tunneling can be used in order to allow the hea= der-compressed packets to travel end-to-end
c) compressed packets belonging to different flows can be multiplexe= d together, in order to share the tunnel overhead.

 

These emerging real-time services which use bare UDP instead of UDP/= RTP have become popular. In addition, a significant effort has been devoted to the deployment of new header compression methods with = improved robustness (ROHC). So there is a need of widening the scope of RFC= 4170 in order to consider these new header compression methods, and also UD= P in addition to UDP/RTP.

 

As a result, the next objectives can be achieved:

 

* Significant bandwidth reductions (as an example, bandwidth savings= of 55% can be obtained for VoIP if IPv4 is used, and 65% using IPv6. For c= ertain online games, 33% of the bandwidth can be saved for IPv4, and 55% when using IPv6).

 

* A reduction of the amount of packets per second managed by the net= work. A reduction factor of 10 or 20 can easily be achieved. This can be tr= anslated into smaller processing delays and energy savings in intermediate routers.
---

Thank you,
Tina

On Jan 8, 2014, at 4:11 PM, "Jose Saldana" <jsald= ana@unizar.es> wrote:

Hi all.
 
First of all, thanks to= David and Luigi for their valuable comments.
 
I will wait for a while= in order to include David=92s comments (perhaps some other people has more= suggestions).
 
These are the improveme= nts of version 10 with respect to v9 (http://www.ietf.org/mail-archive= /web/tcmtf/current/msg00486.html)
 
- I have shortened para= graph 1.
- I have shortened and = merged paragraphs 2 and 3.
- I have moved paragrap= h 4 to the third place, in order to set clearer what we want: replacing RFC= 4170 with a widened proposal. As David suggested, I have also shortened the= text and it is now more straightforward.
- I have clearly stated= which protocols will be used on each layer. The negotiation mechanism is s= till necessary, since different options are considered e.g. for header comp= ression. The one to be used will depend on the scenario and the processing capacity of the two optimizers.<= /div>
- I have significantly = shortened the description of the scenarios.
- I have removed paragr= aph 6, which included the savings figures.
- I have included the r= eplacement of RFC4170 in the first milestone.
 
Thanks!
 
Jose
 
De: Bla= ck, David [mailto:david.black@emc.com] 
Enviado el: s=E1ba= do, 04 de enero de 2014 4:05
Para: Jose Saldana= ; tcmtf@ietf.org;&= nbsp;tsv-area@ietf.org<= span lang=3D"EN-US" style=3D"font-size:10pt; font-family:Tahoma,sans-serif"= >
CC: Martin Stiemer= ling; Black, David
Asunto: RE: TCMTF-= Feedback about a possible BoF in London
 
A = second BoF has the explicit goal of forming a WG, as a third BoF
is= not permitted.  In that regard, the new charter seems long and=
so= mewhat lacking in focus.  Two key things I look for in a proposed
ch= arter are what problem (or problems) the proposed WG is looking to
so= lve and an initial approach to the problem or problems.
&n= bsp;
In= the new draft charter, the problem statement appears to be in
pa= ragraph 4 with paragraph 1 providing important background.  The=
fo= cus of the work appears to be on extending TCRTP (RFC 4170) to
UD= P and to include new compression protocols.  In contrast, I have
a = hard time discerning the initial approach from the new draft charter.
&n= bsp;
In= light of this, there are a few things that I wish the new
dr= aft charter had definitive proposals for:
&n= bsp;
&n= bsp;     a) Whether to replace RFC 4170 vs. write a new= RFC (could be
&n= bsp;           UDP-only o= r UDP + RTP/UDP) as a complement to RFC 4170.
&n= bsp;     b) Whether to use ECRTP, ROHCv2 (RFC 5225) and= /or IPHC (RFC 2507 ?).
&n= bsp;           Non-use of= ECRTP would be a major change to 4170, and I
wo= nder about IPHC, as opposed to the ROHCv2 profiles.
&n= bsp;     c) Analogies to b) for the Mux and Tunnel laye= rs of the stack.
&n= bsp;
Ov= erall, it looks like the first task of the WG is to select the protocol
st= ack to standardize - I have misgivings about that, and would prefer to
se= e a concrete proposal in a crisp charter that ran along the following
li= nes, naming the protocols to be used:
&n= bsp;
1)= RFC 4170 does X, and needs the following changes/additions: X, Y, Z.
2)= The WG will replace RFC 4170 with a new RFC that contains: A, B, C.=
&n= bsp;
A = specific proposal or proposals for the protocol stack or stacks
wo= uld also narrow the scope of item 9 in the charter on the negotiation
me= chanism.  I also don=92t see a goal/milestone listed for an extension = to
or= replacement for RFC 4170.
&n= bsp;
I= =92d prefer to see a much shorter more focused draft charter.  There= =92s a
bu= nch of background material that does not seem crucial to the charter,
st= arting w/paragraphs 2 and 3.
&n= bsp;
Th= anks,
--David
&n= bsp;
From: t= sv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Jose Salda= na
Sent: Friday, Dece= mber 20, 2013 4:26 AM
To: tcmtf@ietf.org; = ;tsv-area@ietf.org
Cc: Martin Stiemer= ling
Subject: TCMTF-Fee= dback about a possible BoF in London
 
Hi all,
 
After the feedback received in the BoF in Berlin, we h= ave updated the TCM-TF charter and the two drafts. We have tried to solve a= ll the problems raised during the session.
 
Our plan is to request a new BoF in London next March,= so we would like to know your opinion about these two questions:
 
 
1.  Is the new, reduced scope of TCM-TF suitable = to form a working group?
 
 
2. We would like to kindly ask people who think that a= TCM-TF Working group should be formed, to come forward and send an e-mail = to the tsv-area@ietf.org  mailing list stating it.
 
 
This feedback will allow us to get a better idea of th= e convenience of a BoF.
 
This is the old one (presented in Berlin): http://www.ietf.org/mail-archi= ve/web/tcmtf/current/msg00368.html
 
In these links you can see the differences between the= new versions of the drafts and the old ones:
http://tools.iet= f.org/rfcdiff?url1=3Ddraft-suznjevic-tsvwg-mtd-tcmtf-02.txt&url2=3Ddraf= t-suznjevic-tsvwg-mtd-tcmtf-01.txt
 
 
The main improvements are:
 
- TCP optimization has been removed
- The classification of the scenarios has been refined= and improved. Some of them have been removed
- A section about energy consumption has been added to= the main draft
- A reference to the potential problem of the MTU and = packet loss has been added
- The problem of the added delays is studied in detail= in the second draft
 
- The improvements of the charter are summarized here:=  http://www.ietf.org= /mail-archive/web/tcmtf/current/msg00466.html
 
 
Best regards,
 
Jose
 
_______________________________________________
tcmtf mailing list
tcmtf@ietf.org
https://www.ietf.org/mailman/listinfo/tcmtf<= /a>



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_g8g+2DCVqy5h+Mk75LOgvw)-- From wes@mti-systems.com Thu Jan 9 10:04:02 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEF81AD9AD for ; Thu, 9 Jan 2014 10:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 VfkDe4qIb3yD for ; Thu, 9 Jan 2014 10:04:01 -0800 (PST) Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id 02CAF1AE045 for ; Thu, 9 Jan 2014 10:04:00 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s09I3owq031201 for ; Thu, 9 Jan 2014 13:03:50 -0500 Received: (qmail 8367 invoked by uid 0); 9 Jan 2014 18:03:50 -0000 X-TCPREMOTEIP: 107.46.60.198 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.46.60.198) by 0 with ESMTPA; 9 Jan 2014 18:03:49 -0000 Message-ID: <52CEE47E.5020804@mti-systems.com> Date: Thu, 09 Jan 2014 13:03:42 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Tina TSOU , Jose Saldana Subject: Re: [tcmtf] TCMTF-Feedback about a possible BoF in London References: <00c401cefd65$6e8ef570$4bace050$@unizar.es> <8D3D17ACE214DC429325B2B98F3AE712026EF2FF8F@MX15A.corp.emc.com>, <004701cf0ccf$4d5826a0$e80873e0$@unizar.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcmtf@ietf.org" , "tsv-area@ietf.org" , Martin Stiemerling X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jan 2014 18:04:02 -0000 On 1/8/2014 7:49 PM, Tina TSOU wrote: > Dear all, > I'm in favor of having a BoF in London, as the following problem > statement seems valid and needs protocol work in IETF. > ... I'm in agreement as well. Parts of the problem statement and the scope of the work might still be tweakable, but I think that overall there is important work for the IETF to do in this area. Due to the things Tina described very well, there will be (and are) products available that attempt to optimize traffic in poorly documented and often poorly conceived ways. These can do more harm and have other mysterious effects on traffic than whatever this working group would create, since it would provide open specifications that could be developed and tested against the concerns of relevant layers and other IETF protocols, and problems and concerns could be addressed. If there are people willing to write the specs *and* people are also able to express interest in writing/deploying/selling code and products that use those specs, then we should certainly be doing this work in the IETF. This will allow: - multiple vendor boxes to interoperate on different sides of a challenged network/link (currently this is beyond the state of the art!) - simplified/standardized management of such boxes - well-understood behavior profiles of such middleboxes and their protocols algorithms If the IETF does not do this work, then I don't believe any of those three benefits/results are likely at all, and the (poor) status quo will continue. -- Wes Eddy MTI Systems From jsaldana@unizar.es Wed Jan 15 01:47:05 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C5F1ADBD1; Wed, 15 Jan 2014 01:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.024 X-Spam-Level: X-Spam-Status: No, score=-4.024 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, ONE_TIME=0.714, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 nGYqbEJXm0X6; Wed, 15 Jan 2014 01:47:02 -0800 (PST) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB541ADF88; Wed, 15 Jan 2014 01:47:01 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s0F9kfZJ011143; Wed, 15 Jan 2014 10:46:41 +0100 From: "Jose Saldana" To: , Subject: Next version (v11) of TCM-TF charter draft Date: Wed, 15 Jan 2014 10:46:52 +0100 Message-ID: <0a5c01cf11d6$b7f08320$27d18960$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A5D_01CF11DF.19B64AB0" X-Mailer: Microsoft Outlook 14.0 Content-language: es Thread-index: Ac8R1lQ09Tz0qQTzQqu6k/HdxtLbAg== X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 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, 15 Jan 2014 09:47:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0A5D_01CF11DF.19B64AB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit According to the comments of David, I have moved the signaling sentences from 5 to 7, and merged the rest of 5 with 6. So this is the new version (Thanks again, David!): Tunneling Compressed Multiplexed Traffic Flows (TCM-TF) charter draft v11 Description of Working Group 1. RFC4170 (TCRTP) defines a method for grouping packets when a number of UDP/RTP VoIP flows share a common path, considering three different layers: ECRTP header compression; PPPMux multiplexing; L2TPv3 tunneling. TCRTP optimizes the traffic, increasing the bandwidth efficiency of VoIP and reduces the amount of packets per second at the same time. 2. However, in the last years, emerging real-time services which use bare UDP instead of UDP/RTP have become popular. Due to the need of interactivity, many of these services use small packets (some tens of bytes). Some other services also send small packets, but they are not delay-sensitive (e.g., instant messaging, m2m packets in sensor networks). In addition, a significant effort has been devoted to the deployment of new header compression methods with improved robustness (ROHC). 3. So there is a need of replacing RFC4170 with an extended solution able to optimize these new flows, also using improved compression methods. The same structure of three layers will be considered: * Header compression: different protocols can be used: no compression, ECRTP, IPHC and ROHC. * Multiplexing: PPPMux will be the option. * Tunneling: the options in this layer are L2TP, GRE and MPLS. 4. New scenarios where bandwidth savings are desirable have been identified, in addition to those considered in RFC4170. In these scenarios, there are moments or places where network capacity gets scarce, so allocating more bandwidth is a possible solution, but it implies a recurring cost. However, the inclusion of a pair of boxes able to optimize the traffic when/where required is a one-time investment. These scenarios can be classified into: * Multidomain, the TCMT-TF tunnel goes all the way from one network edge to another, and can therefore cross several domains. * Single Domain, TCM-TF is only activated inside an ISP, from the edge to border inside the network operator. * Private Solutions. TCM-TF is used to connect private networks geographically apart (e.g. corporation headquarters and subsidiaries), without the ISP being aware or having to manage those flows. * Mixed Scenarios, any combination of the previous ones. 5. A first document (TCM-TF - reference model) will define the different options which can be used at each layer. It will include a detailed specification of the scenarios of interest. 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. The impact on other protocols will also be studied. 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 would be obsoleted. 6. Since standard protocols are being considered at each layer, the signaling methods of those protocols will be used. Thus, interactions with the Working Groups and Areas in which these protocols are developed can be expected. Taking into account that different options will be considered when a pair of TCM-TF optimizers want to establish a session, they will have first to negotiate which concrete option would they use in each layer. This will depend on the protocols that each extreme implements at each level, and in the scenario. So another document (TCM-TF - negotiation protocol) will include: * a mechanism to setup/release a TCM-TF session between an ingress and an egress-optimizer, also including: * a negotiation mechanism to decide the options to use at each layer . 7. As a counterpart of the bandwidth saving, TCM-TF 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 (TCM-TF - recommendations) with useful recommendations in order to decide which packet flows can or can not be multiplexed and how. The document 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. The eventual impact of multiplexing on protocol dynamics (e.g. the loss of a multiplexed packet, MTU-related issues) will also have to be addressed. 8. The working group may identify additional deliverables that are necessary/useful, e.g., a mechanism for a TCM-ingress optimizer to discover an egress optimizer, and vice versa. The working group would re-charter to add them before working on them. 9. Interactions with other Working Groups can be expected, since TCM-TF uses already defined protocols for compression, multiplexing and tunneling (ROHC, PPPMux, MPLS, GRE, L2TP). Goals and Milestones Specification of TCM-TF reference model and the scenarios of interest. This would obsolete RFC4170. Specification of TCM-TF negotiation protocol. Specification of TCM-TF recommendations of using existing traffic classification methods, maximum delay and jitter to add, depending on the service. Current version of Document (TCM-TF - reference model): https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/ Current version of Document (TCM-TF - recommendations): http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ ------=_NextPart_000_0A5D_01CF11DF.19B64AB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

According to the comments of David, I = have moved the signaling sentences from 5 to 7, and merged the rest of 5 = with 6. So this is the new version (Thanks again, = David!):

 

= Tunneling Compressed Multiplexed Traffic Flows (TCM-TF) charter draft = v11

=  

= Description of Working Group

=  

= 1. RFC4170 (TCRTP) defines a method for grouping packets when a number = of UDP/RTP VoIP flows share a common path, considering three different = layers: ECRTP header compression; PPPMux multiplexing; L2TPv3 tunneling. = TCRTP optimizes the traffic, increasing the bandwidth efficiency of VoIP = and reduces the amount of packets per second at the same = time.

= 2. However, in the last years, emerging real-time services which use = bare UDP instead of UDP/RTP have become popular. Due to the need of = interactivity, many of these services use small packets (some tens of = bytes). Some other services also send small packets, but they are not = delay-sensitive (e.g., instant messaging, m2m packets in sensor = networks). In addition, a significant effort has been devoted to the = deployment of new header compression methods with improved robustness = (ROHC).

= 3. So there is a need of replacing RFC4170 with an extended solution = able to optimize these new flows, also using improved compression = methods. The same structure of three layers will be = considered:

= * Header compression: different protocols can be used: no compression, = ECRTP, IPHC and ROHC.

= * Multiplexing: PPPMux will be the option.

= * Tunneling: the options in this layer are L2TP, GRE and = MPLS.

= 4. New scenarios where bandwidth savings are desirable have been = identified, in addition to those considered in RFC4170. In these = scenarios, there are moments or places where network capacity gets = scarce, so allocating more bandwidth is a possible solution, but it = implies a recurring cost. However, the inclusion of a pair of boxes able = to optimize the traffic when/where required is a one-time investment. = These scenarios can be classified into:

= * Multidomain, the TCMT-TF tunnel goes all = the way from one network edge to another, and can therefore cross = several domains.

= * Single Domain, TCM-TF is only activated inside an ISP, from the edge = to border inside the network operator.

= * Private Solutions. TCM-TF is used to connect private networks = geographically apart (e.g. corporation headquarters and subsidiaries), = without the ISP being aware or having to manage those = flows.

= * Mixed Scenarios, any combination of the previous = ones.

= 5. A first document (TCM-TF - reference model) will define the different = options which can be used at each layer. It will include a detailed = specification of the scenarios of interest. 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. The impact on = other protocols will also be studied. 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 would be = obsoleted.

= 6. Since standard protocols are being considered at each layer, the = signaling methods of those protocols will be used. Thus, interactions = with the Working Groups and Areas in which these protocols are developed = can be expected. Taking into account that different options will be = considered when a pair of TCM-TF optimizers want to establish a session, = they will have first to negotiate which concrete option would they use = in each layer. This will depend on the protocols that each extreme = implements at each level, and in the scenario. So another document = (TCM-TF - negotiation protocol) will include:

= * a mechanism to setup/release a TCM-TF session between an ingress and = an egress-optimizer, also including:

= * a negotiation mechanism to decide the options to use at each layer = .

= 7. As a counterpart of the bandwidth saving, TCM-TF 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 (TCM-TF - recommendations) = with useful recommendations in order to decide which packet flows can or = can not be multiplexed and how. The document = 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. The eventual impact of multiplexing on protocol dynamics = (e.g. the loss of a multiplexed packet, MTU-related issues) will also = have to be addressed.

= 8. The working group may identify additional deliverables that are = necessary/useful, e.g., a mechanism for a TCM-ingress optimizer to = discover an egress optimizer, and vice versa. The working group would = re-charter to add them before working on them.

= 9. Interactions with other Working Groups can be expected, since TCM-TF = uses already defined protocols for compression, multiplexing and = tunneling (ROHC, PPPMux, MPLS, GRE, L2TP).

=  

= Goals and Milestones=

= Specification of TCM-TF reference model and the scenarios of interest. = This would obsolete RFC4170.

= Specification of TCM-TF negotiation protocol.

= Specification of TCM-TF recommendations of using existing traffic = classification methods, maximum delay and jitter to add, depending on = the service.

=  

= Current version of Document (= TCM-TF - reference model= ):

= https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/=

=  

= Current version of Document (= TCM-TF - recommendations= ):

= http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/=

 

------=_NextPart_000_0A5D_01CF11DF.19B64AB0-- From jsaldana@unizar.es Fri Jan 17 03:16:22 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A961ADFE2; Fri, 17 Jan 2014 03:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.024 X-Spam-Level: X-Spam-Status: No, score=-4.024 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, ONE_TIME=0.714, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 aJIL-4QqQe3m; Fri, 17 Jan 2014 03:16:18 -0800 (PST) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 491A61ADFC4; Fri, 17 Jan 2014 03:16:16 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s0HBFsqg010380; Fri, 17 Jan 2014 12:15:54 +0100 From: "Jose Saldana" To: , Subject: TCM-TF BoF requested for London Date: Fri, 17 Jan 2014 12:15:57 +0100 Message-ID: <000701cf1375$7ef87ff0$7ce97fd0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01CF137D.E0BEBCB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8TdVYE9YMe4pjTRem/emPLysEdLg== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jan 2014 11:16:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0008_01CF137D.E0BEBCB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi all, =20 A second BoF with the aim of creating a WG has been requested for = London. You can find the details here: = http://trac.tools.ietf.org/bof/trac/wiki#Transport =20 Best regards, =20 Jose * Long name and abbreviation: Tunneling Compressed Multiplexed Traffic = Flows (TCMTF) * Status: WG Forming, 2nd attempt (1st was IETF-87 in Berlin) * Description: RFC4170 (TCRTP) defines a method = for grouping packets when a number of UDP/RTP VoIP flows share a common = path, considering three different layers: ECRTP header compression; = PPPMux multiplexing; L2TPv3 tunneling. TCRTP optimizes the traffic, = increasing the bandwidth efficiency of VoIP and reduces the amount of = packets per second at the same time. However, in the last years, = emerging real-time services which use bare UDP instead of UDP/RTP have = become popular. Due to the need of interactivity, many of these services = use small packets (some tens of bytes). Some other services also send = small packets, but they are not delay-sensitive (e.g., instant = messaging, m2m packets in sensor networks). In addition, a significant = effort has been devoted to the deployment of new header compression = methods with improved robustness (ROHC). So there is a need of replacing = RFC4170 with an extended solution able to optimize these new flows, also = using improved compression methods. The same structure of three layers = (header compression, multiplexing and tunneling) will be considered. New scenarios where bandwidth savings are desirable have been = identified, in addition to those considered in = RFC4170. In these scenarios, there = are moments or places where network capacity gets scarce, so allocating = more bandwidth is a possible solution, but it implies a recurring cost. = However, the inclusion of a pair of boxes able to optimize the traffic = when/where required is a one-time investment. These scenarios can be = classified into: * Multidomain, the TCMT-TF tunnel goes all the way from one network edge = to another, and can therefore cross several domains. * Single Domain, TCM-TF is only activated inside an ISP, from the edge = to border inside the network operator. * Private Solutions. TCM-TF is used to connect private networks = geographically apart (e.g. corporation headquarters and subsidiaries), = without the ISP being aware or having to manage those flows. * Mixed Scenarios, any combination of the previous ones. The BOF will discuss the proposed charter, with the aim of the creation = of a Working Group in order to specify the protocol stack, signaling = mechanisms and maximum added delay recommendations for tunneling, = compressing and multiplexing traffic flows (TCM-TF). This BoF is = intended to form a WG. * The responsible Area Director (AD): Martin Stiemerling, Spencer = Dawkins * BoF Chairs (or the ADs as placeholders): Martin Stiemerling, Spencer = Dawkins * Number of people expected to attend: 80 * Length of session: 1 hour * Conflicts to avoid (Whole area and/or WGs): All TSV WGs, TSVAREA, = 6lowpan, avtcore, avtext, rtcweb, mmusic, l2vpn, l3vpn, softwire * Does it require WebEX?: No * Does it require Meetecho?: Yes, will have a number of remote = participants Links to the mailing list, draft charter if any, relevant = Internet-Drafts, etc.: Mailing List: = =E2=80=8Bhttps://www.ietf.org/mailman/listinfo/tcmtf Draft charter: =E2=80=8B = = =E2=80=8Bhttp://www.ietf.org/mail-archive/web/tcmtf/current/msg00493.html= Relevant I-Ds: =E2=80=8B = = =E2=80=8Bhttps://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/ =E2=80=8B = = =E2=80=8Bhttp://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/= =20 ------=_NextPart_000_0008_01CF137D.E0BEBCB0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi all,

 

A second BoF with the aim of creating a WG has been = requested for London. You can find the details here: http://trac.t= ools.ietf.org/bof/trac/wiki#Transport

 

Best regards,

 

Jose

  • Long = name and abbreviation: Tunneling Compressed Multiplexed Traffic Flows = (TCMTF)
  • Status: = WG Forming, 2nd attempt (1st was IETF-87 in = Berlin)
  • Description:

RFC41= 70 (TCRTP) defines a method for grouping packets when a = number of UDP/RTP VoIP flows share a common path, considering three = different layers: ECRTP header compression; PPPMux multiplexing; L2TPv3 = tunneling. TCRTP optimizes the traffic, increasing the bandwidth = efficiency of VoIP and reduces the amount of packets per second at the = same time. However, in the last years, emerging real-time services which = use bare UDP instead of UDP/RTP have become popular. Due to the need of = interactivity, many of these services use small packets (some tens of = bytes). Some other services also send small packets, but they are not = delay-sensitive (e.g., instant messaging, m2m packets in sensor = networks). In addition, a significant effort has been devoted to the = deployment of new header compression methods with improved robustness = (ROHC).

So there is a = need of replacing RFC41= 70 with an extended solution able to optimize these new = flows, also using improved compression methods. The same structure of = three layers (header compression, multiplexing and tunneling) will be = considered.

New scenarios = where bandwidth savings are desirable have been identified, in addition = to those considered in RFC41= 70. In these scenarios, there are moments or places where = network capacity gets scarce, so allocating more bandwidth is a possible = solution, but it implies a recurring cost. However, the inclusion of a = pair of boxes able to optimize the traffic when/where required is a = one-time investment. These scenarios can be classified into:

  • Multidomain, the TCMT-TF tunnel = goes all the way from one network edge to another, and can therefore = cross several domains.
  • Single = Domain, TCM-TF is only activated inside an ISP, from the edge to border = inside the network operator.
  • Private = Solutions. TCM-TF is used to connect private networks geographically = apart (e.g. corporation headquarters and subsidiaries), without the ISP = being aware or having to manage those flows.
  • Mixed = Scenarios, any combination of the previous = ones.

The BOF will = discuss the proposed charter, with the aim of the creation of a Working = Group in order to specify the protocol stack, signaling mechanisms and = maximum added delay recommendations for tunneling, compressing and = multiplexing traffic flows (TCM-TF). This = BoF is intended to form a = WG.

  • The = responsible Area Director (AD): Martin Stiemerling, Spencer = Dawkins
  • BoF Chairs = (or the ADs as placeholders): Martin Stiemerling, Spencer = Dawkins
  • Number = of people expected to attend: 80
  • Length of session: 1 = hour
  • Conflicts to avoid = (Whole area and/or WGs): All TSV WGs, TSVAREA, 6lowpan, avtcore, avtext, rtcweb, mmusic, l2vpn, = l3vpn, softwire
  • Does it require WebEX?: = No
  • Does it = require Meetecho?: Yes, will have a number = of remote participants

Links to = the mailing list, draft charter if any, relevant Internet-Drafts, = etc.:

Mailing = List: =E2=80=8Bhttps://www.ietf.org/mail= man/listinfo/tcmtf

Draft = charter: =E2=80=8B=E2=80=8Bhttp://www.ietf.org/mail-= archive/web/tcmtf/current/msg00493.html

Relevant = I-Ds: =E2=80=8B=E2=80=8Bhttps://datatracker.ietf.= org/doc/draft-saldana-tsvwg-tcmtf/

=E2=80=8B<= /span>=E2=80=8Bhttp://datatracker.ietf.o= rg/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

 

------=_NextPart_000_0008_01CF137D.E0BEBCB0-- From jsaldana@unizar.es Thu Jan 23 02:17:04 2014 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8F81A0362; Thu, 23 Jan 2014 02:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.035 X-Spam-Level: X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 YNvspA3Ap1aO; Thu, 23 Jan 2014 02:17:02 -0800 (PST) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 655CD1A024C; Thu, 23 Jan 2014 02:17:01 -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 s0NAGttZ011848; Thu, 23 Jan 2014 11:16:55 +0100 From: "Jose Saldana" To: Subject: TCM-TF 2nd BoF approved Date: Thu, 23 Jan 2014 11:17:00 +0100 Message-ID: <00b101cf1824$41224d10$c366e730$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B2_01CF182C.A2E77860" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8YJD87lgl01q8ARx6DhheMRKhZ7g== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jan 2014 10:17:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B2_01CF182C.A2E77860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, As you may know, the second TCM-TF BoF has been approved, and it will be held in London next March. http://trac.tools.ietf.org/bof/trac/wiki#Transport We will work in the next weeks in order to prepare it well. Best regards and thanks, Jose ------=_NextPart_000_00B2_01CF182C.A2E77860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

As you may know, the second TCM-TF = BoF has been approved, and it will be held = in London next March.

 

http://trac.t= ools.ietf.org/bof/trac/wiki#Transport

 

We will work in the next weeks in = order to prepare it well.

 

Best regards and = thanks,

 

Jose

 

------=_NextPart_000_00B2_01CF182C.A2E77860--