I think it could be better to mention the study of specific requiremen= ts on TCMTF by particular use cases, and consider the inclusion of such doc= uments in a future rechartering, rather than committing to have one documen= t (or even several of them) in an issue that we'll have to clarify once the basic framework is in place.

Be goode,

On 19 Jun 2013, at 16:28 , Jose Saldana wrote:

Hi all,

As you may know, if we get the BOF approved, we will h= ave to discuss the WG charter there. Currently these drafts are included in= the WG charter (http://diec.unizar.es/~jsaldana/personal/ietf/tcmt= f_charter_draft.pdf):

1- Draft =93TCM-TF reference model=94: the different o= ptions which can be used at each layer.

2- Draft =93TCM-TF negotiation protocol=94: setup/rele= ase a TCMTF session including a negotiation mechanism to decide the options= to use at each layer.

3- Draft =93TCM-TF recommendations=94: recommendations= in order to decide which packet flows can or can not be multiplexed and ho= w.

For the charter discussion, it would be useful to have= in mind (and perhaps to mention) other potential specific uses of TCM-TF *= that might contribute unique requirements*.

- First of all, I think on the idea proposed by Tomaso= and Matteo (DLR), as said in n.10 of the current draft charter: =93specifi= c uses of TCMTF, such as in wireless and satellite scenarios, could be cons= idered, and it will be studied whether modifications or extensions are required on the protocol=94. It presents d= ifferent and specific requirements.

- Do you think that instant messaging presents unique = requirements with respect to the normal use of TCM-TF? I don=92t think so, = but perhaps someone won=92t agree on this. In fact, instant messaging is al= ready included in the =93TCM-TF recommendations=94 draft.

Any other ideas?

Jose

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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

http://people.tid.es/diego.lopez/

e-mail: diego@tid.es
Tel: +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

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_NVcJOSiRtk5ykHv1NC0RqQ)-- From jsaldana@unizar.es Wed Jun 19 07:54:45 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCDA21F9BC9 for ; Wed, 19 Jun 2013 07:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKDu+UYPniCW for ; Wed, 19 Jun 2013 07:54:41 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6756421F9B80 for ; Wed, 19 Jun 2013 07:54:40 -0700 (PDT) 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 r5JEsWMb024460; Wed, 19 Jun 2013 16:54:33 +0200 From: "Jose Saldana" To: "'Diego R. Lopez'" References: <002801ce6cf9$500feac0$f02fc040$@unizar.es> In-Reply-To: Date: Wed, 19 Jun 2013 16:54:37 +0200 Organization: Universidad de Zaragoza Message-ID: <005501ce6cfc$eb6e5d00$c24b1700$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0056_01CE6D0D.AEF86580" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGRblH9Zk4V+XD8Q7oln4gH4yvd3wHAKZFamakZc3A= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org, Matteo.Berioli@dlr.de, Tomaso.deCola@dlr.de, 'Spencer Dawkins' , 'Martin Stiemerling' Subject: Re: [tcmtf] Other potential specific uses of TCM-TF X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 14:54:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0056_01CE6D0D.AEF86580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, Diego. I think the idea is having these three =93basic=94 drafts, = and also to have in mind some potential ones which could be addressed by re-chartering. We have to first build the basic things, and then go to specific uses. In fact, the current draft charter (n.9) already includes some of that additional ideas: =20 9. If other interesting features are identified, the group would = re-charter and include them, e.g., a=20 mechanism for a multiplexer to discover a de-multiplexer, and vice = versa; a mechanism to select an=20 optimal multiplexer and a de-multiplexer when there are more than one muxer/de-muxer for a flow;=20 dynamically applying TCMTF: a higher entity in charge of deciding when = and where, applying or not=20 TCMTF, and what kind of TCMTF, and what multiplexing period. Additional methods for estimating delay=20 would also be required. =20 I think that in the BOF we should also mention (only mention) the = potential work to be addressed if the WG is created, and the interest on it. =20 However, there is something dangerous: if we =93open=94 too many things, = we may widen the discussion too much, and the BOF may become unfocused. =20 What do you think? =20 Jose =20 De: Diego R. Lopez [mailto:diego@tid.es]=20 Enviado el: mi=E9rcoles, 19 de junio de 2013 16:41 Para: CC: ; ; Spencer Dawkins; ; Martin Stiemerling Asunto: Re: [tcmtf] Other potential specific uses of TCM-TF =20 Hi,=20 =20 I think it could be better to mention the study of specific requirements = on TCMTF by particular use cases, and consider the inclusion of such = documents in a future rechartering, rather than committing to have one document = (or even several of them) in an issue that we'll have to clarify once the = basic framework is in place. =20 Be goode, =20 On 19 Jun 2013, at 16:28 , Jose Saldana wrote: Hi all, =20 As you may know, if we get the BOF approved, we will have to discuss the = WG charter there. Currently these drafts are included in the WG charter ( http://diec.unizar.es/~jsaldana/personal/ietf/tcmtf_charter_draft.pdf): =20 1- Draft =93TCM-TF reference model=94: the different options which can = be used at each layer. 2- Draft =93TCM-TF negotiation protocol=94: setup/release a TCMTF = session including a negotiation mechanism to decide the options to use at each layer. 3- Draft =93TCM-TF recommendations=94: recommendations in order to = decide which packet flows can or can not be multiplexed and how. =20 For the charter discussion, it would be useful to have in mind (and = perhaps to mention) other potential specific uses of TCM-TF *that might = contribute unique requirements*. =20 - First of all, I think on the idea proposed by Tomaso and Matteo (DLR), = as said in n.10 of the current draft charter: =93specific uses of TCMTF, = such as in wireless and satellite scenarios, could be considered, and it will be studied whether modifications or extensions are required on the = protocol=94. It presents different and specific requirements. =20 - Do you think that instant messaging presents unique requirements with respect to the normal use of TCM-TF? I don=92t think so, but perhaps = someone won=92t agree on this. In fact, instant messaging is already included in = the =93TCM-TF recommendations=94 draft. =20 =20 Any other ideas? =20 Jose =20 _______________________________________________ tcmtf mailing list tcmtf@ietf.org https://www.ietf.org/mailman/listinfo/tcmtf =20 -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- =20 =20 _____ =20 Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en = el enlace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx ------=_NextPart_000_0056_01CE6D0D.AEF86580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Yes, Diego. I think the idea is having these three = “basic” drafts, and also to have in mind some potential ones = which could be addressed by re-chartering. We have to first build the = basic things, and then go to specific uses. In fact, the current draft = charter (n.9) already includes some of that additional = ideas:

9. If other interesting features are identified, the group would = re-charter and include them, e.g., a

mechanism for a multiplexer to discover a de-multiplexer, and vice = versa; a mechanism to select an

optimal multiplexer and a de-multiplexer when there are more than one = muxer/de-muxer for a flow;

dynamically applying TCMTF: a higher entity in charge of deciding = when and where, applying or not

TCMTF, and what kind of TCMTF, and what multiplexing period. = Additional methods for estimating delay

would also be required.

I think that in the BOF we should also mention (only mention) the = potential work to be addressed if the WG is created, and the interest on = it.

However, there is something dangerous: if we “open” too = many things, we may widen the discussion too much, and the BOF may = become unfocused.

What do you think?

Jose

De: = Diego R. Lopez [mailto:diego@tid.es]
Enviado el: mi=E9rcoles, = 19 de junio de 2013 16:41
Para: = <jsaldana@unizar.es>
CC: <tcmtf@ietf.org>; = <Tomaso.deCola@dlr.de>; Spencer Dawkins; = <Matteo.Berioli@dlr.de>; Martin Stiemerling
Asunto: Re: = [tcmtf] Other potential specific uses of = TCM-TF

Hi, =

I = think it could be better to mention the study of specific requirements = on TCMTF by particular use cases, and consider the inclusion of such = documents in a future rechartering, rather than committing to have one = document (or even several of them) in an issue that we'll have to = clarify once the basic framework is in = place.

Be goode,

On = 19 Jun 2013, at 16:28 , Jose Saldana wrote:

Hi = all,=

As you may = know, if we get the BOF approved, we will have to discuss the WG charter = there. Currently these drafts are included in the WG charter = (http://diec.unizar.es/~jsaldana/personal/ietf/tcmtf_charter_= draft.pdf):=

1- Draft = “TCM-TF reference model”: the different options which can be = used at each layer.=

2- Draft = “TCM-TF negotiation protocol”: setup/release a TCMTF session = including a negotiation mechanism to decide the options to use at each = layer.=

3- Draft = “TCM-TF recommendations”: recommendations in order to decide = which packet flows can or can not be multiplexed and how.=

For the = charter discussion, it would be useful to have in mind (and perhaps to = mention) other potential specific uses of TCM-TF *that might contribute = unique requirements*.=

- First of = all, I think on the idea proposed by Tomaso and Matteo (DLR), as said in = n.10 of the current draft charter: “specific uses of TCMTF, such = as in wireless and satellite scenarios, could be considered, and it will = be studied whether modifications or extensions are required on the = protocol”. It presents different and specific = requirements.=

- Do you = think that instant messaging presents unique requirements with respect = to the normal use of TCM-TF? I don’t think so, but perhaps someone = won’t agree on this. In fact, instant messaging is already = included in the “TCM-TF recommendations” draft.=

Any other = ideas?=

Jose= =

_________= ______________________________________
tcmtf mailing list
tcmtf@ietf.org
https://www.ietf.org= /mailman/listinfo/tcmtf

--
"Esta vez no fallaremos, Doctor = Infierno"

Dr Diego R. Lopez
Telefonica = I+D

http://people.tid.es/diego.lop= ez/

e-mail: diego@tid.es
Tel: +34 = 913 129 041
Mobile: +34 682 051 = 091
-----------------------------------------

Este mensaje se dirige exclusivamente a su destinatario. Puede = consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo = electr=F3nico en el enlace situado m=E1s abajo.
This message is = intended exclusively for its addressee. We only send and receive email = on the basis of the terms set out at:
http://www.tid.es/E= S/PAGINAS/disclaimer.aspx

------=_NextPart_000_0056_01CE6D0D.AEF86580-- From jsaldana@unizar.es Thu Jun 20 00:23:28 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154C621E80DF for ; Thu, 20 Jun 2013 00:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvxRA+MfczwC for ; Thu, 20 Jun 2013 00:23:22 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id B4B9B21E80CB for ; Thu, 20 Jun 2013 00:23:21 -0700 (PDT) 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 r5K7NIBd010586 for ; Thu, 20 Jun 2013 09:23:18 +0200 From: "Jose Saldana" To: Date: Thu, 20 Jun 2013 09:23:20 +0200 Organization: Universidad de Zaragoza Message-ID: <00e401ce6d87$0abe4fa0$203aeee0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E5_01CE6D97.CE471FA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5thYCCEbR1J90FTvOEaRghIoqCAg== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: [tcmtf] What about TCM-Optimizer --- TCM-Rebuilder? X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 07:23:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00E5_01CE6D97.CE471FA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I was thinking on how should we call the pair of entities performing TCM optimization. It has been set clear that if we call them mux/demux, it is not exact, since we forget the tunnel and compressing layers. Last Monday I proposed "TCM-ingress optimizer" and "TCM-egress optimizer". However, I think these are too long names. I received a suggestion about TCM-optimizer / TCM-deoptimizer. But, who would buy a "deoptimizer"? So I have a better proposal: What about TCM optimizer <-----------------> TCM rebuilder? The egress entity "rebuilds" the packets to their native form. It is its main task: to deliver a packet exactly as it was at the ingress of the tunnel. "TCM reconstructor" could also be ok, but it is longer. Do you like it? Jose ------=_NextPart_000_00E5_01CE6D97.CE471FA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I was thinking on how should we call the pair of entities = performing TCM optimization. It has been set clear that if we call them = mux/demux, it is not exact, since we forget the tunnel and compressing = layers.

Last Monday I proposed “TCM-ingress optimizer” = and “TCM-egress optimizer”. However, I think these are too = long names.

I received a suggestion about TCM-optimizer / = TCM-deoptimizer. But, who would buy a = “deoptimizer”?

So I have a better = proposal:

What about TCM optimizer <-----------------> TCM = rebuilder?

The egress entity “rebuilds” the packets to = their native form. It is its main task: to deliver a packet exactly as = it was at the ingress of the tunnel.

“TCM reconstructor” = could also be ok, but it is longer.

Do you like = it?

Jose

------=_NextPart_000_00E5_01CE6D97.CE471FA0-- From navajas@unizar.es Thu Jun 20 01:04:49 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4AA21E80B0 for ; Thu, 20 Jun 2013 01:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ynskrbU6vS3 for ; Thu, 20 Jun 2013 01:04:43 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id A6A4C11E810E for ; Thu, 20 Jun 2013 01:04:37 -0700 (PDT) Received: from [155.210.156.37] (tele3.cps.unizar.es [155.210.156.37]) (authenticated bits=0) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r5K84RUS026825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 20 Jun 2013 10:04:28 +0200 Message-ID: <51C2B780.5000302@unizar.es> Date: Thu, 20 Jun 2013 10:04:16 +0200 From: =?ISO-8859-15?Q?Juli=E1n_Fern=E1ndez-Navajas?= User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: tcmtf@ietf.org References: <002801ce6cf9$500feac0$f02fc040$@unizar.es> <005501ce6cfc$eb6e5d00$c24b1700$@unizar.es> In-Reply-To: <005501ce6cfc$eb6e5d00$c24b1700$@unizar.es> Content-Type: multipart/alternative; boundary="------------000609050809060300010303" X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [tcmtf] Other potential specific uses of TCM-TF X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 08:04:49 -0000 This is a multi-part message in MIME format. --------------000609050809060300010303 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Hi all, I like to add a potencial new idea which could be addressed by re-chartering. What about the security on the tunnel?. It is possible to add security to TCMTF because it is inherent in the tunnels. And not only consider encryption, but also the digital signature which represents much loss of efficiency in the case of small packages. Someone have more knowledge about this issue? Juli�n El 19/06/2013 16:54, Jose Saldana escribi�: > which could be addressed by re-chartering --------------000609050809060300010303 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit
Hi all,
I like to add a potencial new idea which could be addressed by re-chartering. What about the security on the tunnel?. It is possible to add security to TCMTF because it is inherent in the tunnels. And not only consider encryption, but also the digital signature which represents much loss of efficiency in the case of small packages.
Someone have more knowledge about this issue?
Juli�n

El 19/06/2013 16:54, Jose Saldana escribi�:

which could be addressed by re-chartering

--------------000609050809060300010303-- From Martin.Stiemerling@neclab.eu Thu Jun 20 01:13:22 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB84111E810B for ; Thu, 20 Jun 2013 01:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.42 X-Spam-Level: X-Spam-Status: No, score=-103.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svp6RXJlWuk6 for ; Thu, 20 Jun 2013 01:13:17 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 34CD521E80B0 for ; Thu, 20 Jun 2013 01:13:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 451521045CB for ; Thu, 20 Jun 2013 10:12:55 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBl4ueUKFmJw for ; Thu, 20 Jun 2013 10:12:55 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 298991045CA for ; Thu, 20 Jun 2013 10:12:50 +0200 (CEST) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Jun 2013 10:13:11 +0200 Message-ID: <51C2B996.2060904@neclab.eu> Date: Thu, 20 Jun 2013 10:13:10 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "tcmtf@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] Subject: [tcmtf] Security Threat: Compression Ratio Info-leak Made Easy (CRIME) X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 08:13:22 -0000 Hi all, My fellow Security AD just pointed me to the following security threat that might also applicable in the case of tcmtf: Compression Ratio Info-leak Made Easy (CRIME), see [1]. Just to let you know for your considerations. Martin [1] http://en.wikipedia.org/wiki/CRIME_%28security_exploit%29 -- martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From fpb@tid.es Thu Jun 20 01:20:54 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D408D21F9C68 for ; Thu, 20 Jun 2013 01:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VUNfiuZJYzP for ; Thu, 20 Jun 2013 01:20:47 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFF711E8111 for ; Thu, 20 Jun 2013 01:20:44 -0700 (PDT) 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 <0MOO00397N6IBG@tid.hi.inet> for tcmtf@ietf.org; Thu, 20 Jun 2013 10:20:42 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 43.59.05654.A5BB2C15; Thu, 20 Jun 2013 10:20:42 +0200 (CEST) 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 <0MOO00392N6IBG@tid.hi.inet> for tcmtf@ietf.org; Thu, 20 Jun 2013 10:20:42 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.38]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Thu, 20 Jun 2013 10:20:42 +0200 Date: Thu, 20 Jun 2013 08:19:44 +0000 From: FERNANDO PASCUAL BLANCO In-reply-to: <00e401ce6d87$0abe4fa0$203aeee0$@unizar.es> X-Originating-IP: [10.95.64.115] To: "jsaldana@unizar.es" , "tcmtf@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_UvrwcR6Ytr5a/F7VMwU5zQ)" Content-language: en-US Accept-Language: en-US, es-ES Thread-topic: [tcmtf] What about TCM-Optimizer --- TCM-Rebuilder? Thread-index: Ac5thYCCEbR1J90FTvOEaRghIoqCAgACYrsA user-agent: Microsoft-MacOutlook/14.3.2.130206 X-AuditID: 0a5f4e69-b7f4b6d000001616-fa-51c2bb5a7e13 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42Lhivcz1I3afSjQ4NxEU4tdnzcwOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4/3d5+wFk+wqvk+dydjAuMSsi5GTQ0LARGLH4RVsELaYxIV7 64FsLg4hge2MEq17jzNCOD8ZJXZP+sEE4UxjlPhxoZ0FpIVFQFXi3dl2sHY2AS2J03dXgcWF BRwk2u6tZgexOQUsJK61r2WHWKEg8efcY7AaEYEAid0tB8BsXgFviabzN5kgbEGJH5PvAcU5 OJgFciV6XxmDhJkFxCWaW2+ClTMKyEq8mz+fFWKMo8SNLQeYIGwjiUXPN4KtEhXQk7h5poUV Yq2AxJI955khbFGJl4//sU5gFJ2FZNsshG2zkGyDsA0k3p+bzwxha0ssW/gaytaX2PjlLCOE bSax68NqRmQ1Cxg5VjGKFScVZaZnlOQmZuakGxjpZWTqZeallmxihERd5g7G5TtVDjEKcDAq 8fBqXz4YKMSaWFZcmXuIUYKDWUmEN3XOoUAh3pTEyqrUovz4otKc1OJDjEwcnFINjCvq5j9Z 4Cdb/7bvOK/HK7ZzRRfnPwhn91X5/O/0/3/OHgyJbg9Uc7eaVFvyhGQe9WtjlevQ9AgU7uDZ KXXnwdWpVY9qVvkY7rtenqAQL5/ZkJrBZ+xTkN+lzl3zV+5Qy4mbd5ltNPkEd5Z93C66RPrZ S52QcndF3Uvx0lvsxdIFVf5ET65VYinOSDTUYi4qTgQAYhYCy5gCAAA= Subject: Re: [tcmtf] What about TCM-Optimizer --- TCM-Rebuilder? X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 08:20:54 -0000 --Boundary_(ID_UvrwcR6Ytr5a/F7VMwU5zQ) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Hi Jose, I=B4m not sure about that. Optimizer and rebuilder make me think in very di= fferent things, and actually they should be very similar. I like "TCM-ingre= ss optimizer" and "TCM-egress optimizer", couldn=B4t we use an acronym here= ? "TCM-ingress optimizer": TCM-IO "TCM-egress optimizer": TCM-EO Regards, Fernando Pascual Blancouse Telef=F3nica Global Resources Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F +34913128779 M +34682005168 fpb@tid.es From: "jsaldana@unizar.es" > Organization: Universidad de Zaragoza Reply-To: "jsaldana@unizar.es" > Date: jueves, 20 de junio de 2013 09:23 To: "tcmtf@ietf.org" > Subject: [tcmtf] What about TCM-Optimizer --- TCM-Rebuilder? I was thinking on how should we call the pair of entities performing TCM op= timization. It has been set clear that if we call them mux/demux, it is not= exact, since we forget the tunnel and compressing layers. Last Monday I proposed =93TCM-ingress optimizer=94 and =93TCM-egress optimi= zer=94. However, I think these are too long names. I received a suggestion about TCM-optimizer / TCM-deoptimizer. But, who wou= ld buy a =93deoptimizer=94? So I have a better proposal: What about TCM optimizer <-----------------> TCM rebuilder? The egress entity =93rebuilds=94 the packets to their native form. It is it= s main task: to deliver a packet exactly as it was at the ingress of the tu= nnel. =93TCM reconstructor=94 could also be ok, but it is longer. Do you like it? Jose ________________________________ 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_UvrwcR6Ytr5a/F7VMwU5zQ) Content-id: <03DACA8DA72A874A96C25F9FEF64EF4A@hi.inet> Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable

Hi Jose,

I=B4m = not sure about that. Optimizer and rebuilder make me think in very differen= t things, and actually they should be very similar. I like "TCM-ingres= s optimizer" and "TCM-egress optimizer", couldn=B4t we use an acronym here?

"TCM-ingress optimizer": TCM-IO

"TCM-egress optimizer": TCM-EO

Regards,

Fernando Pascual Blancouse

Telef=F3nica Global Resources

Network Automation and Dynamization

TECHNOLOGY PEOPLE GROUP

F +34913128779

M +34682005168

fpb@tid.es

From: "jsaldana@unizar.es" <jsaldana@unizar.es>
Organization: Universidad de Zarago= za
Reply-To: "jsaldana@unizar.es" <jsaldana@unizar.es>
Date: jueves, 20 de junio de 2013 0= 9:23
To: "tcmtf@ietf.org" <tcm= tf@ietf.org>
Subject: [tcmtf] What about TCM-Opt= imizer --- TCM-Rebuilder?

I was thinking on how should we= call the pair of entities performing TCM optimization. It has been set cle= ar that if we call them mux/demux, it is not exact, since we forget the tun= nel and compressing layers.

Last Monday I proposed =93TCM-i= ngress optimizer=94 and =93TCM-egress optimizer=94. However, I think these = are too long names.

I received a suggestion about T= CM-optimizer / TCM-deoptimizer. But, who would buy a =93deoptimizer=94?

So I have a better proposal:

What about TCM optimizer <--= ---------------> TCM rebuilder?

The egress entity =93rebuilds= =94 the packets to their native form. It is its main task: to deliver a pac= ket exactly as it was at the ingress of the tunnel.

=93TCM reconstructor=94 could a= lso be ok, but it is longer.

Do you like it?

Jose

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_UvrwcR6Ytr5a/F7VMwU5zQ)-- From jsaldana@unizar.es Thu Jun 20 06:47:50 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0385021F9CD3 for ; Thu, 20 Jun 2013 06:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpT5Bans8PUP for ; Thu, 20 Jun 2013 06:47:45 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4B23021F9CCD for ; Thu, 20 Jun 2013 06:47:44 -0700 (PDT) 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 r5KDldRk015799; Thu, 20 Jun 2013 15:47:39 +0200 From: "Jose Saldana" To: "'Martin Stiemerling'" , References: <51C2B996.2060904@neclab.eu> In-Reply-To: <51C2B996.2060904@neclab.eu> Date: Thu, 20 Jun 2013 15:47:42 +0200 Organization: Universidad de Zaragoza Message-ID: <014301ce6dbc$bd0b0ba0$372122e0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFrMO3VStiEqwQ1NQm/OS19NisibpoFFjoA Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [tcmtf] Security Threat: Compression Ratio Info-leak Made Easy (CRIME) X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 13:47:50 -0000 Hi, Martin. I have been reading about the CRIME security exploit, but I think it only affects if you compress the payload of the packet. What we are planning in TCMTF is compressing headers in a certain network segment. After that, the packet is rebuilt to its native form, so the packet arriving to the server (or to the web browser) will have the same header it had when it was sent. If you change the header, the packet does not arrive there. Today we have discussed some security issues here. I hope we will send some ideas to the list soon. Thanks! Jose > -----Mensaje original----- > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de > Martin Stiemerling > Enviado el: jueves, 20 de junio de 2013 10:13 > Para: tcmtf@ietf.org > Asunto: [tcmtf] Security Threat: Compression Ratio Info-leak Made Easy > (CRIME) > > Hi all, > > My fellow Security AD just pointed me to the following security threat that > might also applicable in the case of tcmtf: > Compression Ratio Info-leak Made Easy (CRIME), see [1]. > > Just to let you know for your considerations. > > Martin > > [1] http://en.wikipedia.org/wiki/CRIME_%28security_exploit%29 > > > -- > martin.stiemerling@neclab.eu > > NEC Laboratories Europe > NEC Europe Limited > Registered Office: > Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB > Registered in England 2832014 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf From Martin.Stiemerling@neclab.eu Thu Jun 20 13:13:39 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C751121E805E for ; Thu, 20 Jun 2013 13:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.45 X-Spam-Level: X-Spam-Status: No, score=-103.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHjNt+rpPFLs for ; Thu, 20 Jun 2013 13:13:34 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA6F21E80D3 for ; Thu, 20 Jun 2013 13:13:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id AA9751045ED; Thu, 20 Jun 2013 22:13:11 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGE2evIp8fgG; Thu, 20 Jun 2013 22:13:11 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 8D8861045EC; Thu, 20 Jun 2013 22:12:51 +0200 (CEST) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Jun 2013 22:11:35 +0200 Message-ID: <51C36257.8020406@neclab.eu> Date: Thu, 20 Jun 2013 22:13:11 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: References: <002801ce6cf9$500feac0$f02fc040$@unizar.es> In-Reply-To: <002801ce6cf9$500feac0$f02fc040$@unizar.es> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] Cc: Tomaso.deCola@dlr.de, Matteo.Berioli@dlr.de, jsaldana@unizar.es Subject: [tcmtf] TCMTF BOF approved for IETF-87 in Berlon X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 20:13:39 -0000 Dear all, The TCMTF BOF has been approved for the IETF-87 meeting in Berlin. The chairs for the BOF will be announced shortly. Martin -- IETF Transport Area Director martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From jsaldana@unizar.es Fri Jun 21 00:08:52 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B42D11E813D for ; Fri, 21 Jun 2013 00:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQmmG4hVScMi for ; Fri, 21 Jun 2013 00:08:47 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 64F0F11E8136 for ; Fri, 21 Jun 2013 00:08:46 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r5L78hnJ016563; Fri, 21 Jun 2013 09:08:43 +0200 From: "Jose Saldana" To: "'Martin Stiemerling'" References: <002801ce6cf9$500feac0$f02fc040$@unizar.es> <51C36257.8020406@neclab.eu> In-Reply-To: <51C36257.8020406@neclab.eu> Date: Fri, 21 Jun 2013 09:08:46 +0200 Organization: Universidad de Zaragoza Message-ID: <006901ce6e4e$2c341bc0$849c5340$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: es Thread-index: AQGRblH9Zk4V+XD8Q7oln4gH4yvd3wF5KvHJma318XA= X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org Subject: Re: [tcmtf] TCMTF BOF approved for IETF-87 in Berlon X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 07:08:52 -0000 Thanks a lot, Martin! This is really good news indeed. Now, we have to work hard for preparing it. Thanks to you and to everybody, Jose > -----Mensaje original----- > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de > Martin Stiemerling > Enviado el: jueves, 20 de junio de 2013 22:13 > Para: tcmtf@ietf.org > CC: Tomaso.deCola@dlr.de; Matteo.Berioli@dlr.de; jsaldana@unizar.es > Asunto: [tcmtf] TCMTF BOF approved for IETF-87 in Berlon > > Dear all, > > The TCMTF BOF has been approved for the IETF-87 meeting in Berlin. > > The chairs for the BOF will be announced shortly. > > Martin > > -- > IETF Transport Area Director > > martin.stiemerling@neclab.eu > > NEC Laboratories Europe > NEC Europe Limited > Registered Office: > Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB > Registered in England 2832014 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf From diego@tid.es Sun Jun 23 08:39:58 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF3421F9A3F for ; Sun, 23 Jun 2013 08:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.704 X-Spam-Level: X-Spam-Status: No, score=-5.704 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9KqCllJSuNd for ; Sun, 23 Jun 2013 08:39:54 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id A393421F9302 for ; Sun, 23 Jun 2013 08:39:53 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MOU00M6LRIGRD@tid.hi.inet> for tcmtf@ietf.org; Sun, 23 Jun 2013 17:39:52 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 9B.A4.03142.8C617C15; Sun, 23 Jun 2013 17:39:52 +0200 (CEST) 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 ESMTP id <0MOU00M6HRIGRD@tid.hi.inet> for tcmtf@ietf.org; Sun, 23 Jun 2013 17:39:52 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.38]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Sun, 23 Jun 2013 17:38:52 +0200 Date: Sun, 23 Jun 2013 15:38:51 +0000 From: "Diego R. Lopez" In-reply-to: <51C2B780.5000302@unizar.es> X-Originating-IP: [10.95.64.115] To: =?iso-8859-1?Q?Juli=E1n_Fern=E1ndez-Navajas?= Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_9LehshkNAMef93XZ3vveFQ)" Content-language: en-US Accept-Language: en-US, es-ES Thread-topic: [tcmtf] Other potential specific uses of TCM-TF Thread-index: Ac5s978oBaw7NG94S9C/A9wEOusDMf//5SMAgAADrYCAAR+uAIAFNkgA X-AuditID: 0a5f4068-b7f128e000000c46-6a-51c716c84025 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsXCFe/ApXtC7HigwaX5Uha7Pm9gdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRtey0IK15hUz15o1MJ7W72Lk5JAQMJH4MmEeK4QtJnHh3no2 EFtIYCOjxKqLZl2MXED2D0aJGee2skI40xglHn7/ygxSxSKgKjH560swmw3IftT8mx3EFhaw kTh07QgLiM0poCmx8v4ZNogNChJ/zj0Gi4sIuEoce7iRCcRmFlCXWPNvE1gNr4C3ROOVuywQ tqDEj8n3WCBqciV+Hn4GVS8u0dx6EyzOKCAr8W7+fFaImbYSreveQ813k1gwdRM7xF4BiSV7 zjND2KISLx//Y4X48gijxKENohMYxWYhWTcLybpZSNZB2HoSN6ZOYYOwtSWWLXzNDGHrSsz4 dwiqxkzi277VTMhqFjByrGIUK04qykzPKMlNzMxJNzDUy8jUy8xLLdnECInFjB2My3eqHGIU 4GBU4uE9kHokUIg1say4MvcQowQHs5II74ZrxwKFeFMSK6tSi/Lji0pzUosPMTJxcEo1MBre Uea6tGZ7P9fxGTYbpvH4zuPh3uWy9VixSubcRw4SlXOm6t9vvsre/uEGc2rlB5GWosxzl78U zHOSbT/Pbaguu/KoGov2ckkXB7atPDeLnvov2eHgWF3VWGPaqsz5p8HjyefIaE7lVSmxdWW6 Ao7PFq1e92DRpaNth13lWl+XFu+Ovd28VImlOCPRUIu5qDgRAEGeWh+jAgAA References: <002801ce6cf9$500feac0$f02fc040$@unizar.es> <005501ce6cfc$eb6e5d00$c24b1700$@unizar.es> <51C2B780.5000302@unizar.es> Cc: "" Subject: Re: [tcmtf] Other potential specific uses of TCM-TF X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 15:39:58 -0000 --Boundary_(ID_9LehshkNAMef93XZ3vveFQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi Julian, I definitely think you have a point here. We can consider different securit= y contexts for different tunnels, according to some policy agreed by both e= nd-points at a given tunnel. The security contexts would define encryption, authentication, or both. We'= d have to go into more detail to evaluate potential savings, but I have the= feeling they could be worth considering. The point is that if we go for these different security contexts, we must c= onsider how they can be established by mutual authentication of the tunnel = end-points, and this opens additional issues regarding configuration and cr= ypto material exchange, as well as the possibility of user-initiated authen= tication by means of protocols like OAuth. I'd keep this in the list of the "soon-to-open" issues, focusing on the thr= ee main docs we have been discussing so far. Be goode, On 20 Jun 2013, at 10:04 , Juli=E1n Fern=E1ndez-Navajas wrote: Hi all, I like to add a potencial new idea which could be addressed by re-charterin= g. What about the security on the tunnel?. It is possible to add security t= o TCMTF because it is inherent in the tunnels. And not only consider encryp= tion, but also the digital signature which represents much loss of efficien= cy in the case of small packages. Someone have more knowledge about this issue? Juli=E1n El 19/06/2013 16:54, Jose Saldana escribi=F3: which could be addressed by re-chartering _______________________________________________ tcmtf mailing list tcmtf@ietf.org https://www.ietf.org/mailman/listinfo/tcmtf -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ 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_9LehshkNAMef93XZ3vveFQ) Content-id: <743946CEB336864EABEC221877607C9A@hi.inet> Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi Julian,

I definitely think you have a point here. We can consider different se= curity contexts for different tunnels, according to some policy agreed by b= oth end-points at a given tunnel.

The security contexts would define encryption, authentication, or both= . We'd have to go into more detail to evaluate potential savings, but I hav= e the feeling they could be worth considering.

The point is that if we go for these different security contexts, we m= ust consider how they can be established by mutual authentication of the tu= nnel end-points, and this opens additional issues regarding configuration a= nd crypto material exchange, as well as the possibility of user-initiated authentication by means of proto= cols like OAuth.

I'd keep this in the list of the "soon-to-open" issues, focu= sing on the three main docs we have been discussing so far.

Be goode,

On 20 Jun 2013, at 10:04 , Juli=E1n Fern=E1ndez-Navajas wrote:

Hi all,
I like to add a potencial new idea which could be addressed by re-charterin= g. What about the security on the tunnel?. It is possible to add security t= o TCMTF because it is inherent in the tunnels. And not only consider encryp= tion, but also the digital signature which represents much loss of efficiency in the case of small packages. Someone have more knowledge about this issue?
Juli=E1n

El 19/06/2013 16:54, Jose Saldana escribi=F3:

which= could be addressed by re-chartering

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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

http://people.tid.es/diego.lopez/

e-mail: diego@tid.es
Tel: +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

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_9LehshkNAMef93XZ3vveFQ)-- From jsaldana@unizar.es Mon Jun 24 00:44:34 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25A021E80CA for ; Mon, 24 Jun 2013 00:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.36 X-Spam-Level: X-Spam-Status: No, score=-6.36 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PU4LmwkOWZ9D for ; Mon, 24 Jun 2013 00:44:26 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id B73D521F9D7D for ; Mon, 24 Jun 2013 00:44:22 -0700 (PDT) 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 r5O7iFFR007033; Mon, 24 Jun 2013 09:44:15 +0200 From: "Jose Saldana" To: "'Diego R. Lopez'" , "=?iso-8859-1?Q?'Juli=E1n_Fern=E1ndez-Navajas'?=" References: <002801ce6cf9$500feac0$f02fc040$@unizar.es> <005501ce6cfc$eb6e5d00$c24b1700$@unizar.es> <51C2B780.5000302@unizar.es> In-Reply-To: Date: Mon, 24 Jun 2013 09:44:17 +0200 Organization: Universidad de Zaragoza Message-ID: <00bc01ce70ae$a35d6370$ea182a50$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BD_01CE70BF.66E63370" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGRblH9Zk4V+XD8Q7oln4gH4yvd3wHAKZFaAiNmO5QCxDuZPwISYHSBmXiuoXA= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org Subject: Re: [tcmtf] Other potential specific uses of TCM-TF X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 07:44:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00BD_01CE70BF.66E63370 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Regarding security, we have identified at least one scenario with = security issues: =20 - We have N flows which are traveling through a =93dangerous=94 network = segment (e.g. the =93public=94 Internet). - Instead of adding security to each flow (e.g. using IPSec for each = flow), can we multiplex them and use a single security tunnel instead of N = security tunnels. - It would save bandwidth, since it would avoid N-1 additional security headers. =20 1 2 =85 ---->TCM-ingress ------> non secure network segment ----------> TCM-egress ----> flows rebuilt to their native forms N =20 =20 The questions are: =20 Does this scenario exist? i.e. a number of flows traveling through a =93dangerous=94 network segment. (perhaps a tunnel between appliances = connecting remote offices of a company) =20 Would this be valid for IPSec in tunnel mode? I would avoid N-1 tunnel headers. =20 Would this be valid for IPSec in transport mode? I would avoid N-1 times = the =93Authentication header=94 or the =93Encapsulation Security Header=94. =20 Which would be the best way for adding security to TCM?. Perhaps IPSec = added to the tunneling header would be the most straightforward solution. =20 =20 Jose =20 De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de Diego R. Lopez Enviado el: domingo, 23 de junio de 2013 17:39 Para: Juli=E1n Fern=E1ndez-Navajas CC: Asunto: Re: [tcmtf] Other potential specific uses of TCM-TF =20 Hi Julian,=20 =20 I definitely think you have a point here. We can consider different = security contexts for different tunnels, according to some policy agreed by both end-points at a given tunnel.=20 The security contexts would define encryption, authentication, or both. = We'd have to go into more detail to evaluate potential savings, but I have = the feeling they could be worth considering. =20 The point is that if we go for these different security contexts, we = must consider how they can be established by mutual authentication of the = tunnel end-points, and this opens additional issues regarding configuration and crypto material exchange, as well as the possibility of user-initiated authentication by means of protocols like OAuth. =20 I'd keep this in the list of the "soon-to-open" issues, focusing on the three main docs we have been discussing so far. =20 Be goode, =20 On 20 Jun 2013, at 10:04 , Juli=E1n Fern=E1ndez-Navajas wrote: Hi all, I like to add a potencial new idea which could be addressed by re-chartering. What about the security on the tunnel?. It is possible to = add security to TCMTF because it is inherent in the tunnels. And not only consider encryption, but also the digital signature which represents = much loss of efficiency in the case of small packages. Someone have more knowledge about this issue? Juli=E1n El 19/06/2013 16:54, Jose Saldana escribi=F3: which could be addressed by re-chartering =20 _______________________________________________ tcmtf mailing list tcmtf@ietf.org https://www.ietf.org/mailman/listinfo/tcmtf =20 -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- =20 =20 _____ =20 Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en = el enlace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx ------=_NextPart_000_00BD_01CE70BF.66E63370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Regarding security, we have identified at least one = scenario with security issues:

- We have N flows which are = traveling through a “dangerous” network segment (e.g. the = “public” Internet).
- Instead of adding security to = each flow (e.g. using IPSec for each flow), can we multiplex them and = use a single security tunnel instead of N security = tunnels.
- = It would save bandwidth, since it would avoid N-1 additional security = headers.

1
2
…=A0=A0 ---->TCM-ingress ------> non secure = network segment ----------> TCM-egress ----> flows rebuilt to = their native forms
N

The questions are:

Does this scenario exist? i.e. a = number of flows traveling through a “dangerous” network = segment. (perhaps a tunnel between appliances connecting remote offices = of a company)

Would this be valid for IPSec in tunnel mode? I would avoid = N-1 tunnel headers.

Would this be valid for IPSec in transport mode? I would = avoid N-1 times the “Authentication header” or the = “Encapsulation Security Header”.

Which would be the best way for = adding security to TCM?. Perhaps IPSec added to the tunneling header = would be the most straightforward solution.

Jose

De: = tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de = Diego R. Lopez
Enviado el: domingo, 23 de junio de 2013 = 17:39
Para: Juli=E1n Fern=E1ndez-Navajas
CC: = <tcmtf@ietf.org>
Asunto: Re: [tcmtf] Other potential = specific uses of TCM-TF

Hi Julian, =

I = definitely think you have a point here. We can consider different = security contexts for different tunnels, according to some policy agreed = by both end-points at a given tunnel.
The security contexts would define encryption, = authentication, or both. We'd have to go into more detail to evaluate = potential savings, but I have the feeling they could be worth = considering.

The point is that if we go for these different = security contexts, we must consider how they can be established by = mutual authentication of the tunnel end-points, and this opens = additional issues regarding configuration and crypto material exchange, = as well as the possibility of user-initiated authentication by means of = protocols like OAuth.

I'd keep this in the list of the = "soon-to-open" issues, focusing on the three main docs we have = been discussing so far.

Be goode,

On 20 Jun 2013, at 10:04 , Juli=E1n = Fern=E1ndez-Navajas wrote:

Hi all,
I like to add a potencial new idea which = could be addressed by re-chartering. What about the security on the = tunnel?. It is possible to add security to TCMTF because it is inherent = in the tunnels. And not only consider encryption, but also the digital = signature which represents much loss of efficiency in the case of small = packages.
Someone have more knowledge about this = issue?
Juli=E1n

El 19/06/2013 16:54, Jose Saldana = escribi=F3:
which could be addressed by = re-chartering

_______________________________________________
tcmt= f mailing list
tcmtf@ietf.org
https://www.ietf.org= /mailman/listinfo/tcmtf

--
"Esta vez no fallaremos, Doctor = Infierno"

Dr Diego R. Lopez
Telefonica = I+D
http://people.tid.es/diego.lop= ez/

e-mail: diego@tid.es
Tel: +34 = 913 129 041
Mobile: +34 682 051 = 091
-----------------------------------------

Este mensaje se dirige exclusivamente a su destinatario. Puede = consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo = electr=F3nico en el enlace situado m=E1s abajo.
This message is = intended exclusively for its addressee. We only send and receive email = on the basis of the terms set out at:
http://www.tid.es/E= S/PAGINAS/disclaimer.aspx
------=_NextPart_000_00BD_01CE70BF.66E63370-- From jsaldana@unizar.es Mon Jun 24 04:00:22 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2634411E80FB for ; Mon, 24 Jun 2013 04:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3aQUSiFAYKe for ; Mon, 24 Jun 2013 04:00:14 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 25E9011E8128 for ; Mon, 24 Jun 2013 04:00:10 -0700 (PDT) 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 r5OB03bN023304 for ; Mon, 24 Jun 2013 13:00:07 +0200 From: "Jose Saldana" To: Date: Mon, 24 Jun 2013 13:00:05 +0200 Organization: Universidad de Zaragoza Message-ID: <007e01ce70c9$fe1a0aa0$fa4e1fe0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007F_01CE70DA.C1A328C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5wycGHbApylKz/RhmtAnL3dgONFw== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: [tcmtf] Answers to possible questions in the BOF X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 11:00:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007F_01CE70DA.C1A328C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I would like to start a thread about possible questions people may ask in the BOF. Obviously, we also need answers, so we should cooperate. This is different from the "questions to ask in the BOF". This will be discussed separately. Thanks! Jose ------=_NextPart_000_007F_01CE70DA.C1A328C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I would like to start a thread about possible questions = people may ask in the BOF. Obviously, we also need answers, so we should = cooperate.

This is different from the “questions to ask in the = BOF”. This will be discussed separately.

Thanks!

Jose

------=_NextPart_000_007F_01CE70DA.C1A328C0-- From jsaldana@unizar.es Mon Jun 24 04:21:19 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E2621E80DC for ; Mon, 24 Jun 2013 04:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB7Ywn+85JZM for ; Mon, 24 Jun 2013 04:21:02 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id EFAFB21F9D47 for ; Mon, 24 Jun 2013 04:20:57 -0700 (PDT) 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 r5OBKplr012487; Mon, 24 Jun 2013 13:20:52 +0200 From: "Jose Saldana" To: , References: <007e01ce70c9$fe1a0aa0$fa4e1fe0$@unizar.es> In-Reply-To: <007e01ce70c9$fe1a0aa0$fa4e1fe0$@unizar.es> Date: Mon, 24 Jun 2013 13:20:55 +0200 Organization: Universidad de Zaragoza Message-ID: <009601ce70cc$e4e73500$aeb59f00$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0097_01CE70DD.A870C850" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHxl5HfJe4XxEPJrqhURPk2/vEH5pj+ZmlQ Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [tcmtf] Answers to possible questions in the BOF X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 11:21:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0097_01CE70DD.A870C850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Question: Why Transport Area? Answer: There are three possibilities: RAI, Internet and Transport Area. These are some of the protocols to be used: L2TPv3: Internet Area (RFC 3931, March 2005) PPPMux: Internet Area (RFC 3153, August 2001) ECRTP: RAI Area (RFC 3545, July 2003) ROHC: Transport Area, although it can also compress RTP (RFC 5795, March 2010) 1) RAI TCM-TF is about real-time services. In fact, it would update RFC4170, which was developed within the RAI Area. However, we are proposing to go towards a more generic scheme. RAI area is mainly focused on RTP, and TCM-TF only considers RTP as one of the possibilities. Bare UDP or even TCP flows can be compressed, multiplexed and tunneled. 2) Internet Area or Transport Area? RFC 1122 defines the layers as: - Transport Layer: "The transport layer provides *end-to-end* communication services for applications". - Internet Layer: "All Internet transport protocols use the Internet Protocol (IP) to carry data from source host to destination host. IP is a connectionless or datagram internetwork service, providing *no end-to-end* delivery guarantees". TCMTF is an *end-to-end* solution, requiring some knowledge of the traffic to multiplex, and a synchronization of the context on both sides. So it is clear that it fits in the Transport Area. Jose De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de Jose Saldana Enviado el: lunes, 24 de junio de 2013 13:00 Para: tcmtf@ietf.org Asunto: [tcmtf] Answers to possible questions in the BOF I would like to start a thread about possible questions people may ask in the BOF. Obviously, we also need answers, so we should cooperate. This is different from the "questions to ask in the BOF". This will be discussed separately. Thanks! Jose ------=_NextPart_000_0097_01CE70DD.A870C850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Question: Why Transport = Area?

Answer:

There are = three possibilities: RAI, Internet and Transport Area. These are some of = the protocols to be used:

L2TPv3: = Internet Area (RFC 3931, March 2005)
PPPMux: = Internet Area (RFC 3153, August 2001)
ECRTP: RAI = Area (RFC 3545, July 2003)
ROHC: = Transport Area, although it can also compress RTP (RFC 5795, March = 2010)

1) = RAI
TCM-TF is about real-time services. In fact, it = would update RFC4170, which was developed within the RAI = Area.

However, we = are proposing to go towards a more generic scheme. RAI area is mainly = focused on RTP, and TCM-TF only considers RTP as one of the = possibilities. Bare UDP or even TCP flows can be compressed, multiplexed = and tunneled.

2) Internet = Area or Transport Area?

RFC 1122 = defines the layers as:

- Transport = Layer: “The transport layer provides *end-to-end* = communication services for applications”.

- Internet = Layer: “All Internet transport protocols use the Internet Protocol = (IP) to carry data from source host to destination host. IP is a = connectionless or datagram internetwork service, providing *no = end-to-end* delivery guarantees”.

TCMTF is an = *end-to-end* solution, requiring some knowledge of the traffic to = multiplex, and a synchronization of the context on both = sides.

So it is = clear that it fits in the Transport Area.

Jose

De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] = En nombre de Jose Saldana
Enviado el: lunes, 24 de = junio de 2013 13:00
Para: tcmtf@ietf.org
Asunto: = [tcmtf] Answers to possible questions in the = BOF

I would like to start a thread about possible questions = people may ask in the BOF. Obviously, we also need answers, so we should = cooperate.

This is different from the “questions to ask in the = BOF”. This will be discussed separately.

Thanks!

Jose

------=_NextPart_000_0097_01CE70DD.A870C850-- From jsaldana@unizar.es Mon Jun 24 04:31:17 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927ED21E80DC for ; Mon, 24 Jun 2013 04:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5mniopBY4IC for ; Mon, 24 Jun 2013 04:31:11 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2B49211E8129 for ; Mon, 24 Jun 2013 04:31:10 -0700 (PDT) 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 r5OBV6Qq019940; Mon, 24 Jun 2013 13:31:06 +0200 From: "Jose Saldana" To: , References: <007e01ce70c9$fe1a0aa0$fa4e1fe0$@unizar.es> In-Reply-To: <007e01ce70c9$fe1a0aa0$fa4e1fe0$@unizar.es> Date: Mon, 24 Jun 2013 13:31:10 +0200 Organization: Universidad de Zaragoza Message-ID: <00a401ce70ce$53435aa0$f9ca0fe0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A5_01CE70DF.16CC2AA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHxl5HfJe4XxEPJrqhURPk2/vEH5pj+arnQ Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [tcmtf] Answers to possible questions in the BOF X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 11:31:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A5_01CE70DF.16CC2AA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Question 2: Why creating a Working Group? Why not doing this inside the tsvwg? Answer: This was our first idea, one year ago. But it has become clear that a specific WG is required for this. This in it is something a separate WG should be created to handle, and not something to try to do inside the TSVWG, since there are already a handful of things TSVWG is wrestling with, and it creates too much "context switching" to have a lot of unrelated topics under work there. The question is that the TSVWG group has a lot of interesting things now, and it would be better to discuss TCMTF separately. Any comments? Jose De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de Jose Saldana Enviado el: lunes, 24 de junio de 2013 13:00 Para: tcmtf@ietf.org Asunto: [tcmtf] Answers to possible questions in the BOF I would like to start a thread about possible questions people may ask in the BOF. Obviously, we also need answers, so we should cooperate. This is different from the "questions to ask in the BOF". This will be discussed separately. Thanks! Jose ------=_NextPart_000_00A5_01CE70DF.16CC2AA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Question 2: Why creating a Working = Group? Why not doing this inside the tsvwg?

Answer:

This was = our first idea, one year ago. But it has become clear that a specific WG = is required for this.

This in it = is something a separate WG should be created to handle, and not = something to try to do inside the TSVWG, since there are already a = handful of things TSVWG is wrestling with, and it creates too much = "context switching" to have a lot of unrelated topics under = work there.

The = question is that the TSVWG group has a lot of interesting things now, = and it would be better to discuss TCMTF = separately.

Any = comments?

Jose

De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] = En nombre de Jose Saldana
Enviado el: lunes, 24 de = junio de 2013 13:00
Para: tcmtf@ietf.org
Asunto: = [tcmtf] Answers to possible questions in the = BOF

I would like to start a thread about possible questions = people may ask in the BOF. Obviously, we also need answers, so we should = cooperate.

This is different from the “questions to ask in the = BOF”. This will be discussed separately.

Thanks!

Jose

------=_NextPart_000_00A5_01CE70DF.16CC2AA0-- From navajas@unizar.es Mon Jun 24 07:19:39 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1DD21E8102 for ; Mon, 24 Jun 2013 07:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sonOeCulYcJ6 for ; Mon, 24 Jun 2013 07:19:34 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 87E4821E811D for ; Mon, 24 Jun 2013 07:19:33 -0700 (PDT) Received: from [155.210.156.37] (tele3.cps.unizar.es [155.210.156.37]) (authenticated bits=0) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r5OEJTn4002882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 24 Jun 2013 16:19:29 +0200 Message-ID: <51C85565.3030703@unizar.es> Date: Mon, 24 Jun 2013 16:19:17 +0200 From: =?ISO-8859-15?Q?Juli=E1n_Fern=E1ndez-Navajas?= User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: tcmtf@ietf.org References: <007e01ce70c9$fe1a0aa0$fa4e1fe0$@unizar.es> <00a401ce70ce$53435aa0$f9ca0fe0$@unizar.es> In-Reply-To: <00a401ce70ce$53435aa0$f9ca0fe0$@unizar.es> Content-Type: multipart/alternative; boundary="------------070000080201090605000807" X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [tcmtf] Answers to possible questions in the BOF X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 14:19:40 -0000 This is a multi-part message in MIME format. --------------070000080201090605000807 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit I agree with Jose about the group TSVWG has a lot of interesting things now, and it would be best to discuss TCMTF separately. Juli�n El 24/06/2013 13:31, Jose Saldana escribi�: > TSVWG group has a lot of interesting things now, and it would be > better to discuss TCMTF separately. --------------070000080201090605000807 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit
I agree with Jose about the group TSVWG has a lot of interesting things now, and it would be best to discuss TCMTF separately.
Juli�n

El 24/06/2013 13:31, Jose Saldana escribi�:

TSVWG group has a lot of interesting things now, and it would be better to discuss TCMTF separately.

--------------070000080201090605000807-- From jsaldana@unizar.es Tue Jun 25 01:26:59 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C6821F91A5 for ; Tue, 25 Jun 2013 01:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEiQyeIK0pjq for ; Tue, 25 Jun 2013 01:26:50 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id EB74021F8D10 for ; Tue, 25 Jun 2013 01:26:49 -0700 (PDT) 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 r5P8Qevv022912 for ; Tue, 25 Jun 2013 10:26:45 +0200 From: "Jose Saldana" To: References: <007e01ce70c9$fe1a0aa0$fa4e1fe0$@unizar.es> In-Reply-To: <007e01ce70c9$fe1a0aa0$fa4e1fe0$@unizar.es> Date: Tue, 25 Jun 2013 10:26:42 +0200 Organization: Universidad de Zaragoza Message-ID: <003a01ce717d$bc286e20$34794a60$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01CE718E.7FB13E20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHxl5HfJe4XxEPJrqhURPk2/vEH5pj/xyyg Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [tcmtf] Answers to possible questions in the BOF X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 08:26:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003B_01CE718E.7FB13E20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Question 3: You are talking about real-time services (VoIP, online games, remote desktop). *Why adding a new (multiplexing) delay?* Would it harm the user's experience with the service? Answer 1) We have had that question in mind from the very beginning. We want to save bandwidth and pps, but always preserving subjective quality. In fact, a specific draft has been written including a set of recommendations of the maximum delays that can be tolerated by users of different services. The draft includes references to studies where subjective quality has been evaluated with real people. 2) In addition, our idea is that TCM-TF can be something to be used dynamically when required. Some examples: - I am in the rush hour and I notice a lot of traffic in my network. In order to avoid the collapse, I optimize traffic. I add a small delay, but the bandwidth savings can make it possible that the service still works. - I am an online games provider and I am releasing a new title. The first days, a lot of people will want to play. So, how can I dimension my network? Should I dimension it for the worst case? TCM-TF provides flexibility: there is a tradeoff: a small additional delay as the price for maintaining the service. It should be taken into account that for certain services the bandwidth savings are 50 or even 60%. 3) If I have a high number of flows, I can achieve significant bandwidth savings while adding small delays. Some examples: - 10 VoIP flows G729 can be optimized including one packet from each flow (average additional delay 10ms) and 50% of bandwidth can be saved - if I have 100 flows of a TCP-based online game, I can achieve 45% bandwidth saving with a multiplexing period of 30 ms (average additional delay 15ms) 4) TCM-TF is not only for real-time services. Other small-packet services can be optimized, and in this case the additional delay would not be significant. Any other thoughts? Jose De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de Jose Saldana Enviado el: lunes, 24 de junio de 2013 13:00 Para: tcmtf@ietf.org Asunto: [tcmtf] Answers to possible questions in the BOF I would like to start a thread about possible questions people may ask in the BOF. Obviously, we also need answers, so we should cooperate. This is different from the "questions to ask in the BOF". This will be discussed separately. Thanks! Jose ------=_NextPart_000_003B_01CE718E.7FB13E20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Question 3: You are talking about = real-time services (VoIP, online games, remote desktop). *Why adding = a new (multiplexing) delay?* Would it harm the user’s = experience with the service?

Answer

1) We have = had that question in mind from the very beginning. We want to save = bandwidth and pps, but always preserving subjective quality. In fact, a = specific draft has been written including a set of recommendations of = the maximum delays that can be tolerated by users of different services. = The draft includes references to studies where subjective quality has = been evaluated with real people.

2) In = addition, our idea is that TCM-TF can be something to be used = dynamically when required. Some examples:

- I am in = the rush hour and I notice a lot of traffic in my network. In order to = avoid the collapse, I optimize traffic. I add a small delay, but the = bandwidth savings can make it possible that the service still = works.

- I am an = online games provider and I am releasing a new title. The first days, a = lot of people will want to play. So, how can I dimension my network? = Should I dimension it for the worst case?

TCM-TF = provides flexibility: there is a tradeoff: a small additional delay as = the price for maintaining the service. It should be taken into account = that for certain services the bandwidth savings are 50 or even = 60%.

3) If I = have a high number of flows, I can achieve significant bandwidth savings = while adding small delays. Some examples:
- 10 VoIP = flows G729 can be optimized including one packet from each flow (average = additional delay 10ms) and 50% of bandwidth can be = saved
- if I have 100 flows of a TCP-based online = game, I can achieve 45% bandwidth saving with a multiplexing period of = 30 ms (average additional delay 15ms)

4) TCM-TF = is not only for real-time services. Other small-packet services can be = optimized, and in this case the additional delay would not be = significant.

Any other = thoughts?

Jose

De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] = En nombre de Jose Saldana
Enviado el: lunes, 24 de = junio de 2013 13:00
Para: tcmtf@ietf.org
Asunto: = [tcmtf] Answers to possible questions in the = BOF

I would like to start a thread about possible questions = people may ask in the BOF. Obviously, we also need answers, so we should = cooperate.

This is different from the “questions to ask in the = BOF”. This will be discussed separately.

Thanks!

Jose

------=_NextPart_000_003B_01CE718E.7FB13E20-- From Mirko.Suznjevic@fer.hr Wed Jun 26 01:35:37 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AF121F848A for ; Wed, 26 Jun 2013 01:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQyBxk3SyNP1 for ; Wed, 26 Jun 2013 01:35:32 -0700 (PDT) Received: from mail.fer.hr (mail5.fer.hr [161.53.72.235]) by ietfa.amsl.com (Postfix) with ESMTP id 724C721F8E77 for ; Wed, 26 Jun 2013 01:35:30 -0700 (PDT) Received: from POSTAR.fer.hr (2002:a135:48ed::a135:48ed) by MAIL5.fer.hr (2002:a135:48eb::a135:48eb) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 26 Jun 2013 10:35:28 +0200 Received: from MAIL4.fer.hr ([2002:a135:48ea::a135:48ea]) by POSTAR.fer.hr ([2002:a135:48ed::a135:48ed]) with mapi id 14.02.0342.003; Wed, 26 Jun 2013 10:35:28 +0200 From: =?utf-8?B?TWlya28gU3XFvm5qZXZpxIc=?= To: "tcmtf@ietf.org" Thread-Topic: [tcmtf] Improved version of the tmctf Draft charter (v6) Thread-Index: Ac5oEUJh6X32UcmxT3KmocW8KKc14f//3/+AgAJobQCAA8z8gIAAGU6AgAAkjID///Z7gP/x3DGA Date: Wed, 26 Jun 2013 08:35:26 +0000 Message-ID: References: <51BEE74B.7080104@unizar.es> In-Reply-To: <51BEE74B.7080104@unizar.es> Accept-Language: en-US, hr-HR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.114.38.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [tcmtf] Improved version of the tmctf Draft charter (v6) X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 08:35:37 -0000 SSBhbSBtYXliZSBhIGxpdHRsZSBsYXRlLCBidXQgaSBhZ3JlZSB3aXRoIHRoaXMgdGVybWlub2xv Z3kuDQpNaXJrbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdGNtdGYtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnRjbXRmLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBKb3PDqSBSdWl6DQpTZW50OiBNb25kYXksIEp1bmUgMTcsIDIwMTMgMTI6MzkgUE0NClRvOiB0 Y210ZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0Y210Zl0gSW1wcm92ZWQgdmVyc2lvbiBvZiB0 aGUgdG1jdGYgRHJhZnQgY2hhcnRlciAodjYpDQoNCkhpIGFsbCwNCg0KSSBhZ3JlZSB3aXRoIHlv dS4gIlRDTSBvcHRpbWl6ZXJzIiBhbmQgIlRDTSBmbG93IiB3b3VsZCBiZSBlbm91Z2gsDQoNClBl cGUNCg0KRWwgMTcvMDYvMjAxMyAxMToxMiwgRkVSTkFORE8gUEFTQ1VBTCBCTEFOQ08gZXNjcmli acOzOg0KPiBIaSBKb3NlLCBKdWxpYW4sDQo+DQo+ICAgICAgICAgIFllcywgIlRDTSBvcHRpbWl6 ZXJzIiBhbmQgIlRDTSBmbG93IiBhcmUgcGVyZmVjdCBmb3IgbWUgdG9vLg0KPg0KPiBCZXN0LA0K Pg0KPiBGZXJuYW5kbyBQYXNjdWFsIEJsYW5jbw0KPiBUZWxlZsOzbmljYSBHbG9iYWwgUmVzb3Vy Y2VzDQo+IE5ldHdvcmsgQXV0b21hdGlvbiBhbmQgRHluYW1pemF0aW9uDQo+IFRFQ0hOT0xPR1kg UEVPUExFIEdST1VQDQo+IEYgKzM0OTEzMTI4Nzc5DQo+IE0gKzM0NjgyMDA1MTY4DQo+IGZwYkB0 aWQuZXMNCj4NCj4NCj4NCj4NCj4gT24gMTcvMDYvMTMgMTE6MDIsICJKdWxpw6FuIEZlcm7DoW5k ZXotTmF2YWphcyIgPG5hdmFqYXNAdW5pemFyLmVzPiB3cm90ZToNCj4NCj4+IEkgYWdyZWUgd2l0 aCBGZXJuYW5kbyB0b28sIG5vIGludmVudCBuZXcgRW5nbGlzaCB2ZXJiLg0KPj4gSW4gcmVsYXRp b24gd2l0aCBkdXBsaWNhdGluZyBmbG93IHdvcmQsIGkgdGhpbmsgdGhhdCBpdCBpcyBmaW5lIHRv IA0KPj4gdXNlICJUQ00gZmxvdyIgaW5zdGVhZCBvZiAiVENNVEYgZmxvdyIuDQo+PiBKdWxpw6Fu DQo+Pg0KPj4gRWwgMTcvMDYvMjAxMyA5OjMxLCBKb3NlIFNhbGRhbmEgZXNjcmliacOzOg0KPj4+ IEhpLCBGZXJuYW5kby4NCj4+Pg0KPj4+IEkgYWdyZWUgd2l0aCB5b3UuIFdlIGFyZSB0YWxraW5n IGFib3V0IHN0YW5kYXJkcyBzbyBwcmVjaXNpb24gaXMgDQo+Pj4gaW1wb3J0YW50Lg0KPj4+DQo+ Pj4gSSBkb24ndCB0aGluayB3ZSBzaG91bGQgdXNlIHRoZSAidmVyYiIgInRvIFRDTVRGIiBub3Ig IlRDTVRGaW5nIiBub3IgDQo+Pj4gIlRDTVRGZWQiLiBXZSBjYW5ub3QgaW52ZW50IG5ldyBFbmds aXNoIHZlcmJzLg0KPj4+DQo+Pj4gV2hhdCBhYm91dCAib3B0aW1pemF0aW9uIj8uIFRoaXMgY29u Y2VwdCBzdW1tYXJpemVzIHRoZSB0aHJlZSBsYXllcnMuDQo+Pj4gV2UgY2FuDQo+Pj4gdXNlIGl0 IHRoaXMgd2F5Og0KPj4+DQo+Pj4gLSBBIFRDTVRGIG9wdGltaXplcg0KPj4+DQo+Pj4gLSBBIHBh Y2tldCBvcHRpbWl6ZWQgYnkgbWVhbnMgb2YgVENNVEYNCj4+PiAtIEEgZmxvdyBvcHRpbWl6ZWQg YnkgbWVhbnMgb2YgVENNVEYNCj4+PiAtIEFuIG9wdGltaXplZCBwYWNrZXQNCj4+PiAtIEFuIG9w dGltaXplZCBmbG93DQo+Pj4gLSBBIFRDTVRGLW9wdGltaXplZCBwYWNrZXQNCj4+PiAtIEEgVENN VEYtb3B0aW1pemVkIGZsb3cNCj4+PiAtIEEgVENNVEYgcGFja2V0DQo+Pj4gLSBBIFRDTVRGIGZs b3cNCj4+Pg0KPj4+IC0gdGhlIFRDTVRGIG9wdGltaXphdGlvbiBjYW4gYmUgYXBwbGllZCB0byB0 aGF0IGZsb3cNCj4+PiAtIHRoZSBpbXBhY3Qgb2YgVENNVEYgb3B0aW1pemF0aW9uIG9uIHByb3Rv Y29sIGR5bmFtaWNzDQo+Pj4NCj4+PiBJIGhhdmUgYW5vdGhlciBxdWVzdGlvbiBoZXJlOiBjb3Vs ZCB3ZSB1c2Ugb25seSBUQ00gaW5zdGVhZCBvZiBUQ01URj8NCj4+PiBSZW1lbWJlciB0aGF0IFRG IG1lYW5zICJ0cmFmZmljIGZsb3dzIiwgc28gYSBUQ01URiBmbG93IHdvdWxkIGJlIGEgDQo+Pj4g InR1bm5lbGluZyBjb21wcmVzc2VkIG11bHRpcGxleGVkIHRyYWZmaWMgZmxvd3MgZmxvdyIuIFBl cmhhcHMgYSBUQ00gDQo+Pj4gZmxvdyB3b3VsZCBiZSBlbm91Z2ggaW4gdGhvc2UgY2FzZXMuIFRD TSBkb2VzIG5vdCBoYXZlIGFub3RoZXIgDQo+Pj4gcmVsYXRlZCBtZWFuaW5nIGFuZCBpdCBpcyBz aG9ydGVyIHRoYW4gVENNVEYgDQo+Pj4gKGh0dHA6Ly93d3cuYWNyb255bWZpbmRlci5jb20vVENN Lmh0bWwpDQo+Pj4NCj4+PiAtIEEgVENNIG9wdGltaXplcg0KPj4+IC0gQSBUQ00tb3B0aW1pemVk IGZsb3cNCj4+PiAtIEEgVENNIGZsb3cNCj4+Pg0KPj4+IFdoYXQgZG8geW91IHRoaW5rPw0KPj4+ DQo+Pj4gSm9zZQ0KPj4+DQo+Pj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnRjbXRmIG1haWxpbmcgbGlzdA0KdGNtdGZAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNtdGYNCg== From navajas@unizar.es Wed Jun 26 02:24:25 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E6B21E811E for ; Wed, 26 Jun 2013 02:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EStJOr6w32JE for ; Wed, 26 Jun 2013 02:24:20 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0529121E8122 for ; Wed, 26 Jun 2013 02:24:18 -0700 (PDT) Received: from [155.210.156.37] (tele3.cps.unizar.es [155.210.156.37]) (authenticated bits=0) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r5Q9OAOB016138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 26 Jun 2013 11:24:15 +0200 Message-ID: <51CAB328.5090300@unizar.es> Date: Wed, 26 Jun 2013 11:23:52 +0200 From: =?ISO-8859-15?Q?Juli=E1n_Fern=E1ndez-Navajas?= User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: tcmtf@ietf.org References: <007e01ce70c9$fe1a0aa0$fa4e1fe0$@unizar.es> <003a01ce717d$bc286e20$34794a60$@unizar.es> In-Reply-To: <003a01ce717d$bc286e20$34794a60$@unizar.es> Content-Type: multipart/alternative; boundary="------------080605080605030603060501" X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [tcmtf] Answers to possible questions in the BOF X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 09:24:25 -0000 This is a multi-part message in MIME format. --------------080605080605030603060501 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Another answer for this question is that if you reduce the pps in the network it is possible that the delay also reduces, because the nodes have minor charge of work. Juli�n El 25/06/2013 10:26, Jose Saldana escribi�: > > Question 3: You are talking about real-time services (VoIP, online > games, remote desktop). **Why adding a new (multiplexing) delay?** > Would it harm the user's experience with the service? > > Answer > > 1) We have had that question in mind from the very beginning. We want > to save bandwidth and pps, but always preserving subjective quality. > In fact, a specific draft has been written including a set of > recommendations of the maximum delays that can be tolerated by users > of different services. The draft includes references to studies where > subjective quality has been evaluated with real people. > > 2) In addition, our idea is that TCM-TF can be something to be used > dynamically when required. Some examples: > > - I am in the rush hour and I notice a lot of traffic in my network. > In order to avoid the collapse, I optimize traffic. I add a small > delay, but the bandwidth savings can make it possible that the service > still works. > > - I am an online games provider and I am releasing a new title. The > first days, a lot of people will want to play. So, how can I dimension > my network? Should I dimension it for the worst case? > > TCM-TF provides flexibility: there is a tradeoff: a small additional > delay as the price for maintaining the service. It should be taken > into account that for certain services the bandwidth savings are 50 or > even 60%. > > 3) If I have a high number of flows, I can achieve significant > bandwidth savings while adding small delays. Some examples: > > - 10 VoIP flows G729 can be optimized including one packet from each > flow (average additional delay 10ms) and 50% of bandwidth can be saved > > - if I have 100 flows of a TCP-based online game, I can achieve 45% > bandwidth saving with a multiplexing period of 30 ms (average > additional delay 15ms) > > 4) TCM-TF is not only for real-time services. Other small-packet > services can be optimized, and in this case the additional delay would > not be significant. > > Any other thoughts? > > Jose > > *De:*tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] *En nombre > de *Jose Saldana > *Enviado el:* lunes, 24 de junio de 2013 13:00 > *Para:* tcmtf@ietf.org > *Asunto:* [tcmtf] Answers to possible questions in the BOF > > I would like to start a thread about possible questions people may ask > in the BOF. Obviously, we also need answers, so we should cooperate. > > This is different from the "questions to ask in the BOF". This will be > discussed separately. > > Thanks! > > Jose > > > > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf --------------080605080605030603060501 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit
Another answer for this question is that if you reduce the pps in the network it is possible that the delay also reduces, because the nodes have minor charge of work.
Juli�n

El 25/06/2013 10:26, Jose Saldana escribi�:

Question 3: You are talking about real-time services (VoIP, online games, remote desktop). *Why adding a new (multiplexing) delay?* Would it harm the user’s experience with the service?

�

Answer

�

1) We have had that question in mind from the very beginning. We want to save bandwidth and pps, but always preserving subjective quality. In fact, a specific draft has been written including a set of recommendations of the maximum delays that can be tolerated by users of different services. The draft includes references to studies where subjective quality has been evaluated with real people.

�

�

2) In addition, our idea is that TCM-TF can be something to be used dynamically when required. Some examples:

�

- I am in the rush hour and I notice a lot of traffic in my network. In order to avoid the collapse, I optimize traffic. I add a small delay, but the bandwidth savings can make it possible that the service still works.

�

- I am an online games provider and I am releasing a new title. The first days, a lot of people will want to play. So, how can I dimension my network? Should I dimension it for the worst case?

�

TCM-TF provides flexibility: there is a tradeoff: a small additional delay as the price for maintaining the service. It should be taken into account that for certain services the bandwidth savings are 50 or even 60%.

�

�

3) If I have a high number of flows, I can achieve significant bandwidth savings while adding small delays. Some examples:

- 10 VoIP flows G729 can be optimized including one packet from each flow (average additional delay 10ms) and 50% of bandwidth can be saved

- if I have 100 flows of a TCP-based online game, I can achieve 45% bandwidth saving with a multiplexing period of 30 ms (average additional delay 15ms)

�

�

4) TCM-TF is not only for real-time services. Other small-packet services can be optimized, and in this case the additional delay would not be significant.

�

�

Any other thoughts?

�

Jose

�

De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de Jose Saldana
Enviado el: lunes, 24 de junio de 2013 13:00
Para: tcmtf@ietf.org
Asunto: [tcmtf] Answers to possible questions in the BOF

�

I would like to start a thread about possible questions people may ask in the BOF. Obviously, we also need answers, so we should cooperate.

�

This is different from the “questions to ask in the BOF”. This will be discussed separately.

�

Thanks!

�

Jose

�

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

--------------080605080605030603060501-- From Mirko.Suznjevic@fer.hr Wed Jun 26 02:36:28 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4719811E80CC for ; Wed, 26 Jun 2013 02:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYsU1D5xRjcA for ; Wed, 26 Jun 2013 02:36:22 -0700 (PDT) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) by ietfa.amsl.com (Postfix) with ESMTP id F11D321F93D4 for ; Wed, 26 Jun 2013 02:35:52 -0700 (PDT) Received: from MAIL4.fer.hr ([2002:a135:48ea::a135:48ea]) by MAIL.fer.hr ([2002:a135:48e9::a135:48e9]) with mapi id 14.02.0342.003; Wed, 26 Jun 2013 11:35:48 +0200 From: =?windows-1250?Q?Mirko_Su=9Enjevi=E6?= To: "tcmtf@ietf.org" Thread-Topic: [tcmtf] Answers to possible questions in the BOF Thread-Index: Ac5wycGHbApylKz/RhmtAnL3dgONFwAozNkAADiR09A= Date: Wed, 26 Jun 2013 09:35:47 +0000 Message-ID: References: <007e01ce70c9$fe1a0aa0$fa4e1fe0$@unizar.es> <003a01ce717d$bc286e20$34794a60$@unizar.es> In-Reply-To: <003a01ce717d$bc286e20$34794a60$@unizar.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.114.38.130] Content-Type: multipart/alternative; boundary="_000_E004A7C54DE04F4BB87DB9F32308DA5C0C1C7AMAIL4ferhr_" MIME-Version: 1.0 Subject: Re: [tcmtf] Answers to possible questions in the BOF X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 09:36:28 -0000 --_000_E004A7C54DE04F4BB87DB9F32308DA5C0C1C7AMAIL4ferhr_ Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Hello all, Here i have just a small addition: By using TCM-TF we aim maintain the QoE of the service, or at least minimiz= e the degradation. 1) Recommended limits of multiplexing period are given in order not do= significantly degrade the service (on applicable applications and studies = we aimed at MOS over 4). 2) 1st example of a dynamic scenarios TCMTF is actually reducing laten= cy by preventing congestion (rush hour scenario) 2) 2nd example of the launch of the game scenario TCM-TF provides sign= ificant savings, and increase of the QoE as service unavailability is much = much more QoE degrading for gamers than slight latency increase Also i would emphasize that the added delay is very minimal on links with h= igh packet rate, and that the maximal introduced delay can be controlled wi= th the multiplexing period depending on how much tradeoff is needed or allo= wed. Cheers! Mirko From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On Behalf Of J= ose Saldana Sent: Tuesday, June 25, 2013 10:27 AM To: tcmtf@ietf.org Subject: Re: [tcmtf] Answers to possible questions in the BOF Question 3: You are talking about real-time services (VoIP, online games, r= emote desktop). *Why adding a new (multiplexing) delay?* Would it harm the = user=92s experience with the service? Answer 1) We have had that question in mind from the very beginning. We want to sa= ve bandwidth and pps, but always preserving subjective quality. In fact, a = specific draft has been written including a set of recommendations of the m= aximum delays that can be tolerated by users of different services. The dra= ft includes references to studies where subjective quality has been evaluat= ed with real people. 2) In addition, our idea is that TCM-TF can be something to be used dynamic= ally when required. Some examples: - I am in the rush hour and I notice a lot of traffic in my network. In ord= er to avoid the collapse, I optimize traffic. I add a small delay, but the = bandwidth savings can make it possible that the service still works. - I am an online games provider and I am releasing a new title. The first d= ays, a lot of people will want to play. So, how can I dimension my network?= Should I dimension it for the worst case? TCM-TF provides flexibility: there is a tradeoff: a small additional delay = as the price for maintaining the service. It should be taken into account t= hat for certain services the bandwidth savings are 50 or even 60%. 3) If I have a high number of flows, I can achieve significant bandwidth sa= vings while adding small delays. Some examples: - 10 VoIP flows G729 can be optimized including one packet from each flow (= average additional delay 10ms) and 50% of bandwidth can be saved - if I have 100 flows of a TCP-based online game, I can achieve 45% bandwid= th saving with a multiplexing period of 30 ms (average additional delay 15m= s) 4) TCM-TF is not only for real-time services. Other small-packet services c= an be optimized, and in this case the additional delay would not be signifi= cant. Any other thoughts? Jose De: tcmtf-bounces@ietf.org [mailto:tcmtf-bou= nces@ietf.org] En nombre de Jose Saldana Enviado el: lunes, 24 de junio de 2013 13:00 Para: tcmtf@ietf.org Asunto: [tcmtf] Answers to possible questions in the BOF I would like to start a thread about possible questions people may ask in t= he BOF. Obviously, we also need answers, so we should cooperate. This is different from the =93questions to ask in the BOF=94. This will be = discussed separately. Thanks! Jose --_000_E004A7C54DE04F4BB87DB9F32308DA5C0C1C7AMAIL4ferhr_ Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

Hello a= ll,

Here i = have just a small addition:

By usin= g TCM-TF we aim maintain the QoE of the service, or at least minimize the d= egradation.

= 1)      Recommended limits of multiplexing period are given in order not do signif= icantly degrade the service (on applicable applications and studies we aime= d at MOS over 4).

= 2)      1^st example of a dynamic scenarios TCMTF is actually reducing l= atency by preventing congestion (rush hour scenario)

= 2)      2^nd example of the launch of the game scenario TCM-TF provides = significant savings, and increase of the QoE as service unavailability is m= uch much more QoE degrading for gamers than slight latency increase

Also i = would emphasize that the added delay is very minimal on links with high pac= ket rate, and that the maximal introduced delay can be controlled with the = multiplexing period depending on how much tradeoff is needed or allowed.

Cheers!=
Mirko

From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org= ] On Behalf Of Jose Saldana
Sent: Tuesday, June 25, 2013 10:27 AM
To: tcmtf@ietf.org
Subject: Re: [tcmtf] Answers to possible questions in the BOF

Questio= n 3: You are talking about real-time services (VoIP, online games, remote d= esktop). *Why adding a new (multiplexing) delay?* Would it harm the = user=92s experience with the service?

&n= bsp;

Answer<= o:p>

&n= bsp;

1) We h= ave had that question in mind from the very beginning. We want to save band= width and pps, but always preserving subjective quality. In fact, a specifi= c draft has been written including a set of recommendations of the maximum delays that can be tolerated by users of= different services. The draft includes references to studies where subject= ive quality has been evaluated with real people.

&n= bsp;

&n= bsp;

2) In a= ddition, our idea is that TCM-TF can be something to be used dynamically wh= en required. Some examples:

&n= bsp;

- I am = in the rush hour and I notice a lot of traffic in my network. In order to a= void the collapse, I optimize traffic. I add a small delay, but the bandwid= th savings can make it possible that the service still works.

&n= bsp;

- I am = an online games provider and I am releasing a new title. The first days, a = lot of people will want to play. So, how can I dimension my network? Should= I dimension it for the worst case?

&n= bsp;

TCM-TF = provides flexibility: there is a tradeoff: a small additional delay as the = price for maintaining the service. It should be taken into account that for= certain services the bandwidth savings are 50 or even 60%.

&n= bsp;

&n= bsp;

3) If I= have a high number of flows, I can achieve significant bandwidth savings w= hile adding small delays. Some examples:

- 10 Vo= IP flows G729 can be optimized including one packet from each flow (average= additional delay 10ms) and 50% of bandwidth can be saved=

- if I = have 100 flows of a TCP-based online game, I can achieve 45% bandwidth savi= ng with a multiplexing period of 30 ms (average additional delay 15ms)=

&n= bsp;

&n= bsp;

4) TCM-= TF is not only for real-time services. Other small-packet services can be o= ptimized, and in this case the additional delay would not be significant.

&n= bsp;

&n= bsp;

Any oth= er thoughts?

&n= bsp;

Jose

&n= bsp;

De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de Jose Saldana
Enviado el: lunes, 24 de junio de 2013 13:00
Para: tcmtf@ietf.org
Asunto: [tcmtf] Answers to possible questions in the BOF<= /span>

I would like to start a thread = about possible questions people may ask in the BOF. Obviously, we also need= answers, so we should cooperate.

This is different from the =93q= uestions to ask in the BOF=94. This will be discussed separately.

Thanks!

Jose

--_000_E004A7C54DE04F4BB87DB9F32308DA5C0C1C7AMAIL4ferhr_-- From jsaldana@unizar.es Wed Jun 26 03:49:28 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EBE11E81B0 for ; Wed, 26 Jun 2013 03:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMOzEZFZBqaT for ; Wed, 26 Jun 2013 03:49:23 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB6B11E81AF for ; Wed, 26 Jun 2013 03:49:22 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r5QAnEPc020711 for ; Wed, 26 Jun 2013 12:49:19 +0200 From: "Jose Saldana" To: References: <007e01ce70c9$fe1a0aa0$fa4e1fe0$@unizar.es> In-Reply-To: <007e01ce70c9$fe1a0aa0$fa4e1fe0$@unizar.es> Date: Wed, 26 Jun 2013 12:49:17 +0200 Organization: Universidad de Zaragoza Message-ID: <009901ce725a$d1623360$74269a20$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009A_01CE726B.94EB9FA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHxl5HfJe4XxEPJrqhURPk2/vEH5pkBfNvw Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [tcmtf] Answers to possible questions in the BOF X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 10:49:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009A_01CE726B.94EB9FA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Question 4: Is TCM-TF interesting for the Industry? Should the IETF standardize this? Answer: 1) TCM-TF intends to update RFC4170, which optimizes RTP VoIP traffic. So if RFC4170 was interesting, why not updating it? 2) TCM-TF can be useful in order to save bandwidth in many cases: - Aggregation network of *network operators*: We are saving bandwidth by optimizing and putting together traffic flows. Is this interesting for a network operator? What about overprovisioning? The idea is that there are places and moments in which a number of flows based on small packets are in the same place and at the same moment. Then, TCM-TF can be applied in order to provide flexibility. We are not optimizing the overall Internet traffic, we are optimizing specific flows with very tight delay requirements, which network operators have to take care of in a special way. www.huawei.com/ilink/en/download/HW_193034 - *End to end* optimization: Nowadays, many appliances are used to connect remote offices of the same company (creating a VPN). So if a tunnel exists, why not optimizing this traffic when possible? We would save bandwidth in the access network, where it can be scarce. - Wireless and satellite scenarios. Any other thoughts? Any other scenarios in mind? Potential beneficiaries? Jose De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de Jose Saldana Enviado el: lunes, 24 de junio de 2013 13:00 Para: tcmtf@ietf.org Asunto: [tcmtf] Answers to possible questions in the BOF I would like to start a thread about possible questions people may ask in the BOF. Obviously, we also need answers, so we should cooperate. This is different from the "questions to ask in the BOF". This will be discussed separately. Thanks! Jose ------=_NextPart_000_009A_01CE726B.94EB9FA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Question 4: Is TCM-TF interesting = for the Industry? Should the IETF standardize = this?

Answer:

1) TCM-TF = intends to update RFC4170, which optimizes RTP VoIP traffic. So if = RFC4170 was interesting, why not updating it?

2) TCM-TF = can be useful in order to save bandwidth in many = cases:

- = Aggregation network of *network operators*: We are saving = bandwidth by optimizing and putting together traffic flows. Is this = interesting for a network operator? What about overprovisioning? The = idea is that there are places and moments in which a number of flows = based on small packets are in the same place and at the same moment. = Then, TCM-TF can be applied in order to provide flexibility. We are not = optimizing the overall Internet traffic, we are optimizing specific = flows with very tight delay requirements, which network operators have = to take care of in a special way.
www.huawei.com= /ilink/en/download/HW_193034

- *End = to end* optimization: Nowadays, many appliances are used to connect = remote offices of the same company (creating a VPN). So if a tunnel = exists, why not optimizing this traffic when possible? We would save = bandwidth in the access network, where it can be = scarce.

- Wireless = and satellite scenarios.

Any other = thoughts? Any other scenarios in mind? Potential beneficiaries? =

Jose

De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] = En nombre de Jose Saldana
Enviado el: lunes, 24 de junio de 2013 13:00
Para: = tcmtf@ietf.org
Asunto: [tcmtf] Answers to possible questions = in the BOF

I would like to start a thread about possible questions = people may ask in the BOF. Obviously, we also need answers, so we should = cooperate.

This is different from the “questions to ask in the = BOF”. This will be discussed separately.

Thanks!

Jose

------=_NextPart_000_009A_01CE726B.94EB9FA0-- From dflorez@tid.es Wed Jun 26 06:14:14 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4297F21E8126 for ; Wed, 26 Jun 2013 06:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+3CMQH3SI6h for ; Wed, 26 Jun 2013 06:14:10 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 807ED21E80D7 for ; Wed, 26 Jun 2013 06:14:05 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MP0003TQ4RAHL@tid.hi.inet> for tcmtf@ietf.org; Wed, 26 Jun 2013 15:14:04 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 43.67.03142.B19EAC15; Wed, 26 Jun 2013 15:14:04 +0200 (CEST) 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 ESMTP id <0MP0003AT4RFCD@tid.hi.inet> for tcmtf@ietf.org; Wed, 26 Jun 2013 15:14:03 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.38]) by EX10-HTCAS8-MAD.hi.inet ([fe80::41c8:e965:8a6:de67%11]) with mapi id 14.02.0328.009; Wed, 26 Jun 2013 15:14:03 +0200 Date: Wed, 26 Jun 2013 13:13:00 +0000 From: DAVID FLOREZ RODRIGUEZ In-reply-to: <009901ce725a$d1623360$74269a20$@unizar.es> X-Originating-IP: [10.95.64.115] To: "jsaldana@unizar.es" , "tcmtf@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_gNxRfo+THhb6tpQCNEBrHA)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: [tcmtf] Answers to possible questions in the BOF Thread-index: Ac5wycGHbApylKz/RhmtAnL3dgONFwBgEj+AAAkHEbA= X-AuditID: 0a5f4068-b7f128e000000c46-30-51cae91bdfd1 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsXCFe/ApSvz8lSgwQU3i12fNzA6MHosWfKT KYAxissmJTUnsyy1SN8ugSujv/kIS8H3yYwVPSceMjUwTm1m7GLk5JAQMJE4c+Q3lC0mceHe erYuRi4OIYGNjBKvL35hhHB+MEqc75rPDOFsYJTY8fk2O0gLi4CqRO+x+0wgNpuArsS8PbNZ QGxhAVuJFY+esoHYnAIWElcuQdgSAgoSf849BqsREQiQ2N1yAMzmFfCWaF4+hQnCFpT4Mfke WJxZIFfi+LR7jBC2uMScXxNZQWxGAVmJledPM0LMsZOYvm0j1EwriW9PdrJA7BKQWLLnPDOE LSrx8vE/sF4hgVSJ/XMOM09gFJ2FZN0sJOtmIVkHYetJ3Jg6hQ3C1pZYtvA1M4StKzHj3yEW ZPEFjOyrGMWKk4oy0zNKchMzc9INDPUyMvUy81JLNjFCYixjB+PynSqHGAU4GJV4eE9sOhko xJpYVlyZe4hRgoNZSYT3zfxTgUK8KYmVValF+fFFpTmpxYcYmTg4pRoYG6rUhWYUb2X8V7Wl WPZapvatqWVhhllS84UP6RslTr44122zW3POu5qsmuXGC/7WcmflbEzetOHjtuBQSSm20hte hrPPXnyz54q7Zr2LzNkHb5x6mm6lM9yQdcpmyJvdKNm4w8S0O+GbO7P79vP/i3cGvH8n37tg 6Wy5Rwl7xD/P8Q67eVtaiaU4I9FQi7moOBEABnQmW48CAAA= References: <007e01ce70c9$fe1a0aa0$fa4e1fe0$@unizar.es> <009901ce725a$d1623360$74269a20$@unizar.es> Subject: Re: [tcmtf] Answers to possible questions in the BOF X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 13:14:14 -0000 --Boundary_(ID_gNxRfo+THhb6tpQCNEBrHA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Howdy, Regarding the industry, specially operators' interest. I think that part of= the case relies on the assumption that TCMT could help operators to cope w= ith surges of traffic, either local or global. The case of traffic surges would have also the advantage that the interacti= vity requirement could be relaxed, since there would be more packets to pro= cess in the first time, and most importantly, that the application point of= the algorithms could be shallow or deep in the network, according to traff= ic status. Best Regards, ------------------------------------------------------------------ David Fl=F3rez Rodr=EDguez Phome: 34+913129618 Backup Phone: 34+913128842 e-mail: dflorez@tid.es Network Optimisation and Dynamisation Initiative Telefonica I+D ------------------------------------------------------------------ As if my life were shaven and fitted to a frame and could not breathe without a key and 'twas like midnight, some, when everything that ticked has stopped and space stares all around or grisly frost, first autumn morns, repeal the beating ground but most like chaos, stopless, cool without a chance or spar or even a report of land to justify dispair Emily Dickinson ----------------------------------------------------------------- De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de Jos= e Saldana Enviado el: mi=E9rcoles, 26 de junio de 2013 12:49 Para: tcmtf@ietf.org Asunto: Re: [tcmtf] Answers to possible questions in the BOF Question 4: Is TCM-TF interesting for the Industry? Should the IETF standar= dize this? Answer: 1) TCM-TF intends to update RFC4170, which optimizes RTP VoIP traffic. So i= f RFC4170 was interesting, why not updating it? 2) TCM-TF can be useful in order to save bandwidth in many cases: - Aggregation network of *network operators*: We are saving bandwidth by op= timizing and putting together traffic flows. Is this interesting for a netw= ork operator? What about overprovisioning? The idea is that there are place= s and moments in which a number of flows based on small packets are in the = same place and at the same moment. Then, TCM-TF can be applied in order to = provide flexibility. We are not optimizing the overall Internet traffic, we= are optimizing specific flows with very tight delay requirements, which ne= twork operators have to take care of in a special way. www.huawei.com/ilink/en/download/HW_193034 - *End to end* optimization: Nowadays, many appliances are used to connect = remote offices of the same company (creating a VPN). So if a tunnel exists,= why not optimizing this traffic when possible? We would save bandwidth in = the access network, where it can be scarce. - Wireless and satellite scenarios. Any other thoughts? Any other scenarios in mind? Potential beneficiaries? Jose De: tcmtf-bounces@ietf.org [mailto:tcmtf-bou= nces@ietf.org] En nombre de Jose Saldana Enviado el: lunes, 24 de junio de 2013 13:00 Para: tcmtf@ietf.org Asunto: [tcmtf] Answers to possible questions in the BOF I would like to start a thread about possible questions people may ask in t= he BOF. Obviously, we also need answers, so we should cooperate. This is different from the "questions to ask in the BOF". This will be disc= ussed separately. Thanks! Jose ________________________________ 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_gNxRfo+THhb6tpQCNEBrHA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Howdy,<= /span>

<= /span>

Regardi= ng the industry, specially operators’ interest. I think that part of = the case relies on the assumption that TCMT could help operators to cope wi= th surges of traffic, either local or global.

<= /span>

The cas= e of traffic surges would have also the advantage that the interactivity re= quirement could be relaxed, since there would be more packets to process in= the first time, and most importantly, that the application point of the algorithms could be shallow or deep in t= he network, according to traffic status.

<= /span>

Best Re= gards,

<= /span>

----------= --------------------------------------------------------

<= /span>

David Fl= =F3rez Rodr=EDguez

Phome: 34&= #43;913129618

Backup Pho= ne: 34+913128842

e-mail: dflorez@tid.es

Network Op= timisation and Dynamisation Initiative

Telefonica= I+D

<= /span>

----------= --------------------------------------------------------

<= /span>

As if my l= ife were shaven<= /p>
and fitted= to a frame

and could = not breathe without a key

and 'twas = like midnight, some,

when every= thing that ticked has stopped

and space = stares all around

or grisly = frost, first autumn morns,

repeal the= beating ground<= /p>
but most l= ike chaos, stopless, cool

without a = chance or spar
or even a = report of land
to justify= dispair

<= /span>

&nbs= p;            Emily Dickinson<= /span>

<= /span>

----------= -------------------------------------------------------

<= /span>

De: tcmtf-bo= unces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de Jose Saldana
Enviado el: mi=E9rcoles, 26 de junio de 2013 12:49
Para: tcmtf@ietf.org
Asunto: Re: [tcmtf] Answers to possible questions in the BOF<= /p>

Questio= n 4: Is TCM-TF interesting for the Industry? Should the IETF standardize th= is?

<= /span>

Answer:=

<= /span>

1) TCM-= TF intends to update RFC4170, which optimizes RTP VoIP traffic. So if RFC41= 70 was interesting, why not updating it?

<= /span>

2) TCM-= TF can be useful in order to save bandwidth in many cases:

<= /span>

- Aggre= gation network of *network operators*: We are saving bandwidth by op= timizing and putting together traffic flows. Is this interesting for a netw= ork operator? What about overprovisioning? The idea is that there are places and moments in which a number of flows b= ased on small packets are in the same place and at the same moment. Then, T= CM-TF can be applied in order to provide flexibility. We are not optimizing= the overall Internet traffic, we are optimizing specific flows with very tight delay requirements, which ne= twork operators have to take care of in a special way.

www.h= uawei.com/ilink/en/download/HW_193034

<= /span>

- *E= nd to end* optimization: Nowadays, many appliances are used to connect = remote offices of the same company (creating a VPN). So if a tunnel exists,= why not optimizing this traffic when possible? We would save bandwidth in the access network, where it can be s= carce.

<= /span>

- Wirel= ess and satellite scenarios.

<= /span>

<= /span>

Any oth= er thoughts? Any other scenarios in mind? Potential beneficiaries?

<= /span>

<= /span>

Jose

<= /span>

De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de Jose Saldana
Enviado el: lunes, 24= de junio de 2013 13:00
Para: tcmtf@ietf.org
Asunto: [tcmtf] Answers to possible questions in the BOF

I would like to start a thread = about possible questions people may ask in the BOF. Obviously, we also need= answers, so we should cooperate.

This is different from the R= 20;questions to ask in the BOF”. This will be discussed separately.

Thanks!

Jose

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_gNxRfo+THhb6tpQCNEBrHA)-- From dwing@cisco.com Wed Jun 26 13:13:54 2013 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAFC11E81F5 for ; Wed, 26 Jun 2013 13:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLIxW3WK4EgW for ; Wed, 26 Jun 2013 13:13:50 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9A00D11E81F7 for ; Wed, 26 Jun 2013 13:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15005; q=dns/txt; s=iport; t=1372277630; x=1373487230; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=Wfx5TqQAoE/hf+rfEEHV7phZeZF4sKM0NkQM8iyGsgg=; b=CSYwQvO5tRu5B47dqZqMSWAIRbWnb94whd8kWnBanw0uwhjPH/41SwIE VEDUXJlePCSID+KZ0LdxTR2GshenAwx0239hGNXRsVUdwpLJCpG/hpaB3 i6OsvyW4b7wAQtVWJmL+vk9OJd2BZZHR3/2qBQ11DCjPl4+w+JGjB2OqF c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAHBKy1GrRDoH/2dsb2JhbABbgkVEMQG/RYEEFnSCIwEBAQMBAQEBRiULBQsLPwcnHxEGExoEh2oFDbl7jX6BTQYBgwJhA4kiilGDUoYhiySDMRw X-IronPort-AV: E=Sophos;i="4.87,946,1363132800"; d="scan'208,217";a="84437661" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 26 Jun 2013 20:13:47 +0000 Received: from [10.32.240.195] ([10.32.240.195]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r5QKDkQm023427; Wed, 26 Jun 2013 20:13:46 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_DE18961D-A275-4E13-A3AE-46172E3E1092" Mime-Version: 1.0 (Mac OS X Mail 6.5 $1508$) From: Dan Wing In-Reply-To: <009901ce725a$d1623360$74269a20$@unizar.es> Date: Wed, 26 Jun 2013 13:13:46 -0700 Message-Id: <2543ED38-A2FF-49D7-85E0-4790A31415BC@cisco.com> References: <007e01ce70c9$fe1a0aa0$fa4e1fe0$@unizar.es> <009901ce725a$d1623360$74269a20$@unizar.es> To: X-Mailer: Apple Mail (2.1508) Cc: tcmtf@ietf.org Subject: Re: [tcmtf] Answers to possible questions in the BOF X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Tunneling Compressed Multiplexed Traffic Flows $TCMTF$ discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 20:13:54 -0000 --Apple-Mail=_DE18961D-A275-4E13-A3AE-46172E3E1092 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 26, 2013, at 3:49 AM, Jose Saldana wrote: > Question 4: Is TCM-TF interesting for the Industry? Should the IETF = standardize this? > =20 > Answer: > =20 > 1) TCM-TF intends to update RFC4170, which optimizes RTP VoIP traffic. = So if RFC4170 was interesting, why not updating it? > =20 > 2) TCM-TF can be useful in order to save bandwidth in many cases: > =20 > - Aggregation network of *network operators*: We are saving bandwidth = by optimizing and putting together traffic flows. Is this interesting = for a network operator? What about overprovisioning? The idea is that = there are places and moments in which a number of flows based on small = packets are in the same place and at the same moment. Then, TCM-TF can = be applied in order to provide flexibility. We are not optimizing the = overall Internet traffic, we are optimizing specific flows with very = tight delay requirements, which network operators have to take care of = in a special way. > www.huawei.com/ilink/en/download/HW_193034 > =20 > - *End to end* optimization: Nowadays, many appliances are used to = connect remote offices of the same company (creating a VPN). So if a = tunnel exists, why not optimizing this traffic when possible? We would = save bandwidth in the access network, where it can be scarce. > =20 > - Wireless and satellite scenarios. "Cisco adds IP multiplexing to mobile satellite package", April 2012, = http://www.networkworld.com/news/2012/040912-cisco-ip-multiplexing-258082.= html > =20 > =20 > Any other thoughts? Any other scenarios in mind? Potential = beneficiaries? Some networks, today, use cRTP (RFC2508) on their access links. This = gives bandwidth savings on the access link, but consumes considerable = CPU horsepower on the aggregation router (to perform cRTP), but provides = no bandwidth savings across the network core. If, instead, the = bandwidth could be saved on the access link, across the core, and on the = far-end access link -- all without the CPU impact on the aggregation = router -- it is a considerable win. -d > =20 > =20 > Jose > =20 > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre = de Jose Saldana > Enviado el: lunes, 24 de junio de 2013 13:00 > Para: tcmtf@ietf.org > Asunto: [tcmtf] Answers to possible questions in the BOF > =20 > I would like to start a thread about possible questions people may ask = in the BOF. Obviously, we also need answers, so we should cooperate. > =20 > This is different from the =93questions to ask in the BOF=94. This = will be discussed separately. > =20 > Thanks! > =20 > Jose > =20 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf --Apple-Mail=_DE18961D-A275-4E13-A3AE-46172E3E1092 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 jsaldana@unizar.es> = wrote:

Question 4: Is TCM-TF interesting for the Industry? Should the = IETF standardize this?
Answer:

1) TCM-TF intends to update RFC4170, = which optimizes RTP VoIP traffic. So if RFC4170 was interesting, why not = updating it?
2) TCM-TF can be useful in order to = save bandwidth in many cases:
- Aggregation network of *network = operators*: We are saving bandwidth by optimizing and putting = together traffic flows. Is this interesting for a network operator? What = about overprovisioning? The idea is that there are places and moments in = which a number of flows based on small packets are in the same place and = at the same moment. Then, TCM-TF can be applied in order to provide = flexibility. We are not optimizing the overall Internet traffic, we are = optimizing specific flows with very tight delay requirements, which = network operators have to take care of in a special = way.

- *End to end* optimization: = Nowadays, many appliances are used to connect remote offices of the same = company (creating a VPN). So if a tunnel exists, why not optimizing this = traffic when possible? We would save bandwidth in the access network, = where it can be scarce.
- Wireless and satellite = scenarios.

"Cisco= adds IP multiplexing to mobile satellite package", April 2012, http://www.networkworld.com/news/2012/040912-cisco-ip-multip= lexing-258082.html

Any other thoughts? Any other = scenarios in mind? Potential = beneficiaries?