RE: [tcmtf] Next steps with TCMTF

From jsaldana@unizar.es Tue Sep 4 00:33:33 2012 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 0D69B21F84F8 for ; Tue, 4 Sep 2012 00:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_60=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wv7HrRr+kovp for ; Tue, 4 Sep 2012 00:33:32 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4C93321F84B8 for ; Tue, 4 Sep 2012 00:33:25 -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 q847XLpq029513 for ; Tue, 4 Sep 2012 09:33:21 +0200 From: "Jose Saldana" To: Date: Tue, 4 Sep 2012 09:33:24 +0200 Organization: Universidad de Zaragoza Message-ID: <004201cd8a6f$914f03d0$b3ed0b70$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01CD8A80.54D84900" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2Kb1VdGCuze+c2Sv2rvwz0+MSLMw== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: [tcmtf] A possible new scenario: cable modem 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, 04 Sep 2012 07:33:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0043_01CD8A80.54D84900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, This is the first message after August Holidays. I hope everybody is back in the office. As far as I know, cable modem networks also group traffic from a geographical zone, or a suburb, etc. Could this be another scenario for TCMTF? Jose ------=_NextPart_000_0043_01CD8A80.54D84900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

This is the first message after August Holidays. I hope = everybody is back in the office.

As far as I know, cable modem = networks also group traffic from a geographical zone, or a suburb, etc. = Could this be another scenario for TCMTF?

Jose

------=_NextPart_000_0043_01CD8A80.54D84900-- From jsaldana@unizar.es Tue Sep 4 00:40:44 2012 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 451CF21F84F8 for ; Tue, 4 Sep 2012 00:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=1.799, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1SnmCmQxV-B for ; Tue, 4 Sep 2012 00:40:43 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1B721F84AE for ; Tue, 4 Sep 2012 00:40:43 -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 q847ebn5030547; Tue, 4 Sep 2012 09:40:37 +0200 From: "Jose Saldana" To: Date: Tue, 4 Sep 2012 09:40:40 +0200 Organization: Universidad de Zaragoza Message-ID: <005601cd8a70$957ed560$c07c8020$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0057_01CD8A81.5907A560" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2KcHryAwwN880YT661jzVtSnJyRw== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: Matteo.Berioli@dlr.de, Tomaso.deCola@dlr.de Subject: [tcmtf] Discussing M2M scenario and savings 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, 04 Sep 2012 07:40:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0057_01CD8A81.5907A560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi again, We already discussed some points about the M2M scenario at the beginning of August. We are currently studying this, and we have built some figures, in collaboration with people from DLR (Tomaso and Matteo). You can find the figures here: http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_savings.pdf http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenario.pdf Perhaps we could comment them, in order to discuss this scenario, and we may find new ones in which TCMTF can be useful. Thanks, Jose ------=_NextPart_000_0057_01CD8A81.5907A560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi again,

We already discussed some points about the M2M scenario at = the beginning of August. We are currently studying this, and we have = built some figures, in collaboration with people from DLR (Tomaso and = Matteo). You can find the figures here:

http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_savings= .pdf

http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenar= io.pdf

Perhaps we could comment them, in order to discuss this = scenario, and we may find new ones in which TCMTF can be = useful.

Thanks,

Jose

------=_NextPart_000_0057_01CD8A81.5907A560-- From fpb@tid.es Tue Sep 4 03:27:28 2012 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 9590221F84FA for ; Tue, 4 Sep 2012 03:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgatF8cb6RCp for ; Tue, 4 Sep 2012 03:27:27 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id F0C6321F84D4 for ; Tue, 4 Sep 2012 03:27:26 -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 <0M9T00BHKMDO2M@tid.hi.inet> for tcmtf@ietf.org; Tue, 04 Sep 2012 12:27:24 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id D5.C5.21591.C87D5405; Tue, 04 Sep 2012 12:27:24 +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 <0M9T00BHGMDN2M@tid.hi.inet> for tcmtf@ietf.org; Tue, 04 Sep 2012 12:27:23 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([fe80::a90d:2f68:6fb8:5c75]) by ex10-htcas4-mad.hi.inet ([::1]) with mapi id 14.02.0318.001; Tue, 04 Sep 2012 12:26:44 +0200 Date: Tue, 04 Sep 2012 10:27:22 +0000 From: FERNANDO PASCUAL BLANCO In-reply-to: <005601cd8a70$957ed560$c07c8020$@unizar.es> X-Originating-IP: [10.95.64.115] To: "tcmtf@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ttUwY3wmkGCdTprBAmsjxw)" Content-language: en-US Accept-Language: en-US Thread-topic: [tcmtf] Discussing M2M scenario and savings Thread-index: Ac2KcHryAwwN880YT661jzVtSnJyRwAFrH2w X-AuditID: 0a5f4e69-b7f0e6d000005457-a0-5045d78c2585 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAKsWRmVeSWpSXmKPExsXCFe9nqNtz3TXA4G8Hr8WuzxsYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsf7sbpaCQ6YVvR9+sTYwNut3MXJySAiYSEy+dYEdwhaTuHBv PVsXIxeHkMB2RonvVycyQTg/GSVen/4PViUksJRR4t39OhCbRUBV4s/f3WwgNpuAlsTpu6tY QGxhAQuJzpMbWEFsTiD7/5fdLBAbFCT+nHsMZosA9Xa8aQWyOTh4BbwlLh2zAAnzCghK/Jh8 D6yEWSBXYuqSlYwQtrhEc+tNsDgj0KHfT61hghhjKTFp/gJWCNtIYu7a7awQqwQkluw5zwxh i0q8fPyPFeJ8c4nPU5YwTmAUnYVk3Swk62YhWQdh60gs2P2JDcLWlli28DUzjH3mwGMmZPEF jOyrGMWKk4oy0zNKchMzc9INjPQyMvUy81JLNjFCoitzB+PynSqHGAU4GJV4eF9yugYIsSaW FVfmHmKU5GBSEuUNuQQU4kvKT6nMSCzOiC8qzUktPsQowcGsJMJ7ezVQjjclsbIqtSgfJiXD waEkwStxDSglWJSanlqRlpkDTCEwaSYOTpB2HqD2dSA1vMUFibnFmekQ+VOMklLivDogCQGQ REZpHlzvK0ZxoCOFeb+BZHmAyQ6u6xXQQCagga7vXUAGliQipKQaGGULHkxYty1lTZNxnVvr b5PNZ9SfbLmkV1yn8PXzcl7+P5GJczX/esT0XolkN7yRekfYZmmE0Mumy3yObX4blutdqn0z 0/CorYhKg0VwcOf6WcebfLtO67ye6n/6FO+9PXN2tE/nW8hy9ucM68b3gmtmLJzguHH9qrbm haEGDRP15xm6BZ0qEVJiKc5INNRiLipOBABKPKeQMwMAAA== References: <005601cd8a70$957ed560$c07c8020$@unizar.es> Subject: Re: [tcmtf] Discussing M2M scenario and savings 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: Tue, 04 Sep 2012 10:27:28 -0000 --Boundary_(ID_ttUwY3wmkGCdTprBAmsjxw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, Yes, M2M sensor networks are a very good example in order to save bandwidth in long distance/big latency/low bandwidth links, links were the cost per bit is high. Do you think network carriers operating this kind of links (satellite links or long distance wires) would be interested in apply TCMTF? Regards, Fernando From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On Behalf Of Jose Saldana Sent: martes, 04 de septiembre de 2012 9:41 To: tcmtf@ietf.org Cc: Matteo.Berioli@dlr.de; Tomaso.deCola@dlr.de Subject: [tcmtf] Discussing M2M scenario and savings Hi again, We already discussed some points about the M2M scenario at the beginning of August. We are currently studying this, and we have built some figures, in collaboration with people from DLR (Tomaso and Matteo). You can find the figures here: http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_savings.pdf http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenario.pdf Perhaps we could comment them, in order to discuss this scenario, and we may find new ones in which TCMTF can be useful. Thanks, Jose ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s 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 --Boundary_(ID_ttUwY3wmkGCdTprBAmsjxw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi all,

Yes, M2M sensor networks are a very good example in order to save bandwidth in long distance/big latency/low bandwidth links, links were the cost per bit is high. Do you think network carriers operating this kind of links (satellite links or long distance wires) would be interested in apply TCMTF?

Regards,

Fernando

From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On Behalf Of Jose Saldana
Sent: martes, 04 de septiembre de 2012 9:41
To: tcmtf@ietf.org
Cc: Matteo.Berioli@dlr.de; Tomaso.deCola@dlr.de
Subject: [tcmtf] Discussing M2M scenario and savings

Hi again,

We already discussed some points about the M2M scenario at the beginning of August. We are currently studying this, and we have built some figures, in collaboration with people from DLR (Tomaso and Matteo). You can find the figures here:

http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_savings.pdf

http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenario.pdf

Perhaps we could comment them, in order to discuss this scenario, and we may find new ones in which TCMTF can be useful.

Thanks,

Jose

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más 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
--Boundary_(ID_ttUwY3wmkGCdTprBAmsjxw)-- From dflorez@tid.es Thu Sep 6 01:30:16 2012 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 9962121F847B for ; Thu, 6 Sep 2012 01:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euTy3SNXZ0Qj for ; Thu, 6 Sep 2012 01:30:15 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1F25C21F8468 for ; Thu, 6 Sep 2012 01:30:10 -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 <0M9X00IUH6A8QW@tid.hi.inet> for tcmtf@ietf.org; Thu, 06 Sep 2012 10:30:08 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 4C.E8.11959.01F58405; Thu, 06 Sep 2012 10:30:08 +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 <0M9X00IUC6A8QW@tid.hi.inet> for tcmtf@ietf.org; Thu, 06 Sep 2012 10:30:08 +0200 (MEST) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Thu, 06 Sep 2012 10:30:08 +0200 Date: Thu, 06 Sep 2012 10:30:07 +0200 From: DAVID FLOREZ RODRIGUEZ In-reply-to: <004201cd8a6f$914f03d0$b3ed0b70$@unizar.es> To: "jsaldana@unizar.es" , "tcmtf@ietf.org" Message-id: <0986BE7EB220D848BEF7ADDF53B634196ABA34B599@EXCLU2K7.hi.inet> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_K9n+nM2rYadZLaLqBIiEqA)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: [tcmtf] A possible new scenario: cable modem Thread-index: Ac2Kb1VdGCuze+c2Sv2rvwz0+MSLMwBmgLSg acceptlanguage: es-ES, en-US X-AuditID: 0a5f4068-b7fec6d000002eb7-3c-50485f108b05 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLKsWRmVeSWpSXmKPExsXCFe/ApSsQ7xFg8L1Zw2LX5w2MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK6J91iLlgeXLF0Vt/mRsYWyK7GDk5JARMJI6cn8IGYYtJXLi3 Hsjm4hAS2Mgo8WbhAVYI5yejxIZT75kgnEZGibZ3i8BaWARUJWbPuMsOYrMJ6ErM2zObBcQW FrCU+HxhHSuIzSlgIbHoOUSNiECAxO6WA2A1vAKeEpM2rWKDsAUlfky+BxZnFsiV+DD1ODOE LS4x59dEsDmMArISK8+fZuxi5ACaYyVxqzEXYqSRxIrb3cwQJTIS/5fvZYH4RkBiyZ7zzBC2 qMTLx//AxggJmEusPvKIfQKj6Cwkm2ch2TwLyWYIW0/ixtQpbBC2tsSyha+hanQlZvw7xIIs voCRfRWjWHFSUWZ6RkluYmZOuoGhXkamXmZeaskmRkh8ZexgXL5T5RCjAAejEg/vihL3ACHW xLLiytxDjJIcTEqivMdiPAKE+JLyUyozEosz4otKc1KLDzFKcDArifBamgLleFMSK6tSi/Jh UjIcHEoSvPtjgVKCRanpqRVpmTnAJAKTZuLgBGnnAWpfBVLDW1yQmFucmQ6RP8WoynFy2Zr7 jEIsefl5qVLivA9BigRAijJK8+DmvGIUBzpYmHcLSJYHmAbhJrwCGs4ENNz1vQvI8JJEhJRU A2N/j6Xu7a27l/YpaVTbXW833XZmSt/NnXa5Z998jVtiGBVa5rzQO46L48jKigOvHQ6wbXw+ oWJOskDeKpbnW8yMrrUVx22pFZ/HkHG/mkfib+OhOXMFrZuir8hlhvosDfxw4btmRNm/yT7r GezO9WlYP/Xrc4wxkriYk7eaNUQ762aN+cEX3UosxRmJhlrMRcWJAETs8xJAAwAA References: <004201cd8a6f$914f03d0$b3ed0b70$@unizar.es> Subject: Re: [tcmtf] A possible new scenario: cable modem 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, 06 Sep 2012 08:30:16 -0000 --Boundary_(ID_K9n+nM2rYadZLaLqBIiEqA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi All, As far as we know, even though we are not directly involved in this world, = the cable modem aggregators play a similar role to ONT/BRAS in fixed networ= ks. They appear to be in to flavours L2 or L3. In the case of a L3 one, the= protocol could be used directly in it (or in the vicinity), if we had to c= ope with a L2 one, the TCMTF aggregator should be moved to the nearest BRAS= . My two (devaluated) cents Best Regards, David Fl=F3rez ------------------------------------------------------------------ David Fl=F3rez Rodr=EDguez tfno: 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: martes, 04 de septiembre de 2012 9:33 Para: tcmtf@ietf.org Asunto: [tcmtf] A possible new scenario: cable modem Hi all, This is the first message after August Holidays. I hope everybody is back i= n the office. As far as I know, cable modem networks also group traffic from a geographic= al zone, or a suburb, etc. Could this be another scenario for TCMTF? 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_K9n+nM2rYadZLaLqBIiEqA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hi All,

As far as we know, eve= n though we are not directly involved in this world, the cable modem aggreg= ators play a similar role to ONT/BRAS in fixed networks. They appear to be = in to flavours L2 or L3. In the case of a L3 one, the protocol could be used directly in it (or in the vicinity= ), if we had to cope with a L2 one, the TCMTF aggregator should be moved to= the nearest BRAS.

My two (devaluated) ce= nts

Best Regards,

David Fl=F3rez

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

David Fl=F3rez = Rodr=EDguez

tfno: 34+91= 3128842

e-mail: dflorez= @tid.es

Network Optimisation and Dy= namisation Initiative

Telefonica I+D

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

As if my life were shaven

and fitted to a frame

and could not breathe witho= ut a key

and 'twas like midnight, so= me,

when everything that ticked= has stopped

and space stares all around=

or grisly frost, first autu= mn morns,

repeal the beating ground

but most like chaos, stople= ss, cool

without a chance or spar

or even a report of land

to justify dispair

&nb= sp; Emily Dickinson

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

De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de Jose Saldana
Enviado el: martes, 04 de septiembre de 2012 9:33
Para: tcmtf@ietf.org
Asunto: [tcmtf] A possible new scenario: cable modem

Hi all,

This is the first message after August Holidays. I h= ope everybody is back in the office.

As far as I know, cable modem networks also group tr= affic from a geographical zone, or a suburb, etc. Could this be another sce= nario for TCMTF?

Jose

Este mensaje se dirige exclu= sivamente 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 re= ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
--Boundary_(ID_K9n+nM2rYadZLaLqBIiEqA)-- From jsaldana@unizar.es Thu Sep 13 08:20:26 2012 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 0947621F855F for ; Thu, 13 Sep 2012 08:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.337 X-Spam-Level: X-Spam-Status: No, score=-4.337 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jfp61kApc+pU for ; Thu, 13 Sep 2012 08:20:23 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD3121F852E for ; Thu, 13 Sep 2012 08:20:22 -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 q8DFKGhQ011454; Thu, 13 Sep 2012 17:20:17 +0200 From: "Jose Saldana" To: "'FERNANDO PASCUAL BLANCO'" , References: <005601cd8a70$957ed560$c07c8020$@unizar.es> In-Reply-To: Date: Thu, 13 Sep 2012 17:20:23 +0200 Organization: Universidad de Zaragoza Message-ID: <009501cd91c3$4bdedf40$e39c9dc0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0096_01CD91D4.0F67AF40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMJsXMGv09m9IoM+WJU0jVlsq/J6wH0qQ4/lQB8oCA= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [tcmtf] Discussing M2M scenario and savings 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, 13 Sep 2012 15:20:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0096_01CD91D4.0F67AF40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Fernando, sorry for the delay (one week, I=92m afraid). =20 I don=92t know who is the one interested on using TCMTF: =20 - If you are a costumer, and you have to pay for a satellite = link or a long distance wire, perhaps you are the one interested on using end-to-end TCMTF, since you will save bandwidth or packets per second or money. If you have e.g. two offices, one in America and other one in = Europe, you may be interested on placing a device for multiplexing a number of = VoIP calls between them. You have one advantage: the flows have the same = origin and destination, so header compression is effective. - If you are the operator of the satellite, you have another problem: you may have to check every flow, and try to group them. = Perhaps it may be easy, but if you want to save headers, you need flows with the = same origin and destination. =20 I think that there are different scenarios, and each =93actor=94 may try = to use TCMTF in the best place: a high number of flows, with small packets, and sharing the same origin and destination. =20 Do you agree?=20 =20 Jose =20 De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de FERNANDO PASCUAL BLANCO Enviado el: martes, 04 de septiembre de 2012 12:27 Para: tcmtf@ietf.org Asunto: Re: [tcmtf] Discussing M2M scenario and savings =20 Hi all, =20 Yes, M2M sensor networks are a very good example in = order to save bandwidth in long distance/big latency/low bandwidth links, links = were the cost per bit is high. Do you think network carriers operating this = kind of links (satellite links or long distance wires) would be interested in apply TCMTF? =20 Regards, =20 Fernando =20 From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On Behalf = Of Jose Saldana Sent: martes, 04 de septiembre de 2012 9:41 To: tcmtf@ietf.org Cc: Matteo.Berioli@dlr.de; Tomaso.deCola@dlr.de Subject: [tcmtf] Discussing M2M scenario and savings =20 Hi again, =20 We already discussed some points about the M2M scenario at the beginning = of August. We are currently studying this, and we have built some figures, = in collaboration with people from DLR (Tomaso and Matteo). You can find the figures here: =20 http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_savings.pdf =20 http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenario.pdf =20 Perhaps we could comment them, in order to discuss this scenario, and we = may find new ones in which TCMTF can be useful. =20 Thanks, =20 Jose =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_0096_01CD91D4.0F67AF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, Fernando, sorry for the delay = (one week, I’m afraid).

I = don’t know who is the one interested on using = TCMTF:

- = If you are a costumer, and you have to pay for a = satellite link or a long distance wire, perhaps you are the one = interested on using end-to-end TCMTF, since you will save bandwidth or = packets per second or money. If you have e.g. two offices, one in = America and other one in Europe, you may be interested on placing a = device for multiplexing a number of VoIP calls between them. You have = one advantage: the flows have the same origin and destination, so header = compression is effective.

- = If you are the operator of the satellite, you = have another problem: you may have to check every flow, and try to group = them. Perhaps it may be easy, but if you want to save headers, you need = flows with the same origin and destination.

I think = that there are different scenarios, and each “actor” may try = to use TCMTF in the best place: a high number of flows, with small = packets, and sharing the same origin and = destination.

Do you = agree?

Jose

De: = tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de = FERNANDO PASCUAL BLANCO
Enviado el: martes, 04 de = septiembre de 2012 12:27
Para: = tcmtf@ietf.org
Asunto: Re: [tcmtf] Discussing M2M scenario and = savings

Hi all,

&= nbsp; Yes, M2M sensor networks are a very good example = in order to save bandwidth in long distance/big latency/low bandwidth = links, links were the cost per bit is high. Do you think network = carriers operating this kind of links (satellite links or long distance = wires) would be interested in apply TCMTF?

Regards,

Fernando

From:= tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@iet= f.org] On Behalf Of Jose Saldana
Sent: martes, 04 = de septiembre de 2012 9:41
To: tcmtf@ietf.org
Cc: Matteo.Berioli@dlr.de; Tomaso.deCola@dlr.de
Subje= ct: [tcmtf] Discussing M2M scenario and = savings

Hi again,

http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_savings= .pdf

http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenar= io.pdf

Perhaps we could comment them, in order to discuss this = scenario, and we may find new ones in which TCMTF can be = useful.

Thanks,

Jose

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_0096_01CD91D4.0F67AF40-- From jsaldana@unizar.es Mon Sep 17 00:35:24 2012 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 7E7D421F855B for ; Mon, 17 Sep 2012 00:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.27 X-Spam-Level: X-Spam-Status: No, score=-4.27 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1GmVXWUNq78 for ; Mon, 17 Sep 2012 00:35:23 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 669FA21F8559 for ; Mon, 17 Sep 2012 00:35:20 -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 q8H7ZGh1000990 for ; Mon, 17 Sep 2012 09:35:17 +0200 From: "Jose Saldana" To: References: <005601cd8a70$957ed560$c07c8020$@unizar.es> <009501cd91c3$4bdedf40$e39c9dc0$@unizar.es> <003e01cd94a6$5dfe20b0$19fa6210$@unizar.es> In-Reply-To: <003e01cd94a6$5dfe20b0$19fa6210$@unizar.es> Date: Mon, 17 Sep 2012 09:35:18 +0200 Organization: Universidad de Zaragoza Message-ID: <004901cd94a6$fce54be0$f6afe3a0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 thread-index: AQMJsXMGv09m9IoM+WJU0jVlsq/J6wH0qQ4/Ag8+d/gBb9sirJTqTLqg Content-language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: [tcmtf] RV: Discussing M2M scenario and savings 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, 17 Sep 2012 07:35:24 -0000 Only a comment to avoid misunderstanding: the last sentence of the = previous message =93=85 sharing the same origin and destination=94 is not = correct. What you need is a common path shared by a number of flows. Multiplexing can be applied in the whole path or even in a single hop (e.g. the critical bottleneck). Regards, Jose ---------------------- De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de = Jose Saldana Enviado el: jueves, 13 de septiembre de 2012 17:20 Para: 'FERNANDO PASCUAL BLANCO'; tcmtf@ietf.org Asunto: Re: [tcmtf] Discussing M2M scenario and savings Hi, Fernando, sorry for the delay (one week, I=92m afraid). I don=92t know who is the one interested on using TCMTF: - If you are a costumer, and you have to pay for a satellite link or a = long distance wire, perhaps you are the one interested on using end-to-end = TCMTF, since you will save bandwidth or packets per second or money. If you = have e.g. two offices, one in America and other one in Europe, you may be interested on placing a device for multiplexing a number of VoIP calls between them. You have one advantage: the flows have the same origin and destination, so header compression is effective. - If you are the operator of the satellite, you have another problem: = you may have to check every flow, and try to group them. Perhaps it may be = easy, but if you want to save headers, you need flows with the same origin and destination. I think that there are different scenarios, and each =93actor=94 may try = to use TCMTF in the best place: a high number of flows, with small packets, and sharing the same origin and destination. Do you agree?=20 Jose ----------------------------- De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de FERNANDO PASCUAL BLANCO Enviado el: martes, 04 de septiembre de 2012 12:27 Para: tcmtf@ietf.org Asunto: Re: [tcmtf] Discussing M2M scenario and savings Hi all, =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Yes, M2M sensor networks = are a very good example in order to save bandwidth in long distance/big latency/low bandwidth links, links = were the cost per bit is high. Do you think network carriers operating this = kind of links (satellite links or long distance wires) would be interested in apply TCMTF? =A0 Regards, =A0 Fernando =A0 From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On Behalf = Of Jose Saldana Sent: martes, 04 de septiembre de 2012 9:41 To: tcmtf@ietf.org Cc: Matteo.Berioli@dlr.de; Tomaso.deCola@dlr.de Subject: [tcmtf] Discussing M2M scenario and savings =A0 Hi again, =A0 We already discussed some points about the M2M scenario at the beginning = of August. We are currently studying this, and we have built some figures, = in collaboration with people from DLR (Tomaso and Matteo). You can find the figures here: =A0 http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_savings.pdf =A0 http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenario.pdf =A0 Perhaps we could comment them, in order to discuss this scenario, and we = may find new ones in which TCMTF can be useful. =A0 Thanks, =A0 Jose =A0 From fpb@tid.es Mon Sep 17 02:41:21 2012 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 62E7D21F85C6 for ; Mon, 17 Sep 2012 02:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=2.501, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuE7IVCeST76 for ; Mon, 17 Sep 2012 02:41:20 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id A418921F85B8 for ; Mon, 17 Sep 2012 02:41:19 -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 <0MAH0046VMWTHT@tid.hi.inet> for tcmtf@ietf.org; Mon, 17 Sep 2012 11:41:17 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id AA.2A.17235.D30F6505; Mon, 17 Sep 2012 11:41:17 +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 <0MAH0046QMWTHT@tid.hi.inet> for tcmtf@ietf.org; Mon, 17 Sep 2012 11:41:17 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([fe80::a90d:2f68:6fb8:5c75]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0318.001; Mon, 17 Sep 2012 11:41:17 +0200 Date: Mon, 17 Sep 2012 09:40:24 +0000 From: FERNANDO PASCUAL BLANCO In-reply-to: <004901cd94a6$fce54be0$f6afe3a0$@unizar.es> X-Originating-IP: [10.95.64.115] To: "jsaldana@unizar.es" , "tcmtf@ietf.org" Message-id: Content-id: <660B9AC4C0212547AAD86D5448585C4C@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, es-ES Thread-topic: [tcmtf] RV: Discussing M2M scenario and savings Thread-index: AQHNlKbkaEvzwHAXlk2LYZpZzes8epeOSJWA user-agent: Microsoft-MacOutlook/14.2.3.120616 X-AuditID: 0a5f4068-b7f666d000004353-2c-5056f03d6ca8 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsXCFe/ApWv7ISzA4G+/vMWuzxsYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsWf5YqaCv0oVKxexNjCekeli5OSQEDCR2LjqHxOELSZx4d56 NhBbSGAjo8S8mxxdjFxA9k9Gib9T57JAOEsZJf58XsECUsUioCrxePEHVhCbTUBL4vTdVWBx YQFbiUU7fzB2MXJwcApYSFyYpA2xQEHiz7nHYCUiAgESu1sOsICU8AqoSUzfkQMSZhYwk3i+ 7CrYRF4BQYkfk++xQMT1JD7+uc0IYYtLNLfehIprSzx5dwGsnlFAVuLd/PmsEOPtJLZ9/8MO YRtJLL1xH6xXFGjOhne/WSDOEZBYsuc8M4QtKvHy8T/WCYzis5CcMQvJGbOQnDELyRmzkJyx gJF1FaNYcVJRZnpGSW5iZk66gaFeRqZeZl5qySZGSGRl7GBcvlPlEKMAB6MSD+8Bx+AAIdbE suLK3EOMkhxMSqK8G96EBQjxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4X0AkuNNSaysSi3Kh0nJ cHAoSfCKvwdKCRalpqdWpGXmANMHTJqJgxOknQeovRmkhre4IDG3ODMdIn+KUVJKnNcWJCEA ksgozYPrfcUoDnSkMK8vSJYHmOjgul4BDWQCGljxBGxgSSJCSqqBsaiPpedq2Hm1ZZ064r/c ZzPemu+c1iX+xqlmS+iFs7H+c9cY9NyxDqqaXd7g/yrujWuuwX//CVsrSp6fPug+d93WDQbW p79/2zr/NYtSQ/52ZW/zuE3XuRe7HH/Z/y9wxcG/NkZsbw4InT26bp7DLI3fjLpa4bUv2Y0X BV5e73pli5+8p/xDPyWW4oxEQy3mouJEAHTG0l0xAwAA Subject: Re: [tcmtf] RV: Discussing M2M scenario and savings 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, 17 Sep 2012 09:41:21 -0000 Hi Jose, That was my point: a network carrier has a satellite link or long distance wire and decides to implant TCMTF in that hop (tipically a bottleneck). IP sources/destinations may not be the same (multiple flows are sharing the same link) and QoS requirements may not be the same (same reason). Nevertheless, although header compression is not optimal (different sources/destinations), any save in that link would be appreciated. Saludos, Fernando Pascual Blanco Telef=F3nica Global Resources Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F +34913128779 M +34682005168 fpb@tid.es On 17/09/12 09:35, "Jose Saldana" wrote: >Only a comment to avoid misunderstanding: the last sentence of the >previous >message =B3=8A sharing the same origin and destination=B2 is not correct. = What >you >need is a common path shared by a number of flows. Multiplexing can be >applied in the whole path or even in a single hop (e.g. the critical >bottleneck). > >Regards, > >Jose >---------------------- > >De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de >Jose >Saldana >Enviado el: jueves, 13 de septiembre de 2012 17:20 >Para: 'FERNANDO PASCUAL BLANCO'; tcmtf@ietf.org >Asunto: Re: [tcmtf] Discussing M2M scenario and savings > >Hi, Fernando, sorry for the delay (one week, I=B9m afraid). > >I don=B9t know who is the one interested on using TCMTF: > >- If you are a costumer, and you have to pay for a satellite link or a >long >distance wire, perhaps you are the one interested on using end-to-end >TCMTF, >since you will save bandwidth or packets per second or money. If you have >e.g. two offices, one in America and other one in Europe, you may be >interested on placing a device for multiplexing a number of VoIP calls >between them. You have one advantage: the flows have the same origin and >destination, so header compression is effective. >- If you are the operator of the satellite, you have another problem: you >may have to check every flow, and try to group them. Perhaps it may be >easy, >but if you want to save headers, you need flows with the same origin and >destination. > >I think that there are different scenarios, and each =B3actor=B2 may try t= o >use >TCMTF in the best place: a high number of flows, with small packets, and >sharing the same origin and destination. > >Do you agree? > >Jose > >----------------------------- > >De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de >FERNANDO PASCUAL BLANCO >Enviado el: martes, 04 de septiembre de 2012 12:27 >Para: tcmtf@ietf.org >Asunto: Re: [tcmtf] Discussing M2M scenario and savings > >Hi all, > > Yes, M2M sensor networks are a very good example in order >to >save bandwidth in long distance/big latency/low bandwidth links, links >were >the cost per bit is high. Do you think network carriers operating this >kind >of links (satellite links or long distance wires) would be interested in >apply TCMTF? > >Regards, > >Fernando > >From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On Behalf Of >Jose Saldana >Sent: martes, 04 de septiembre de 2012 9:41 >To: tcmtf@ietf.org >Cc: Matteo.Berioli@dlr.de; Tomaso.deCola@dlr.de >Subject: [tcmtf] Discussing M2M scenario and savings > >Hi again, > >We already discussed some points about the M2M scenario at the beginning >of >August. We are currently studying this, and we have built some figures, in >collaboration with people from DLR (Tomaso and Matteo). You can find the >figures here: > >http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_savings.pdf > >http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenario.pdf > >Perhaps we could comment them, in order to discuss this scenario, and we >may >find new ones in which TCMTF can be useful. > >Thanks, > >Jose > > >_______________________________________________ >tcmtf mailing list >tcmtf@ietf.org >https://www.ietf.org/mailman/listinfo/tcmtf ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx From gorry@erg.abdn.ac.uk Tue Sep 18 11:46:41 2012 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 3E4A221F8516 for ; Tue, 18 Sep 2012 11:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.392 X-Spam-Level: X-Spam-Status: No, score=-101.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZArDOncwPYeR for ; Tue, 18 Sep 2012 11:46:40 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2028821F8518 for ; Tue, 18 Sep 2012 11:46:40 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id DE3202B45A4; Tue, 18 Sep 2012 19:46:38 +0100 (BST) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 97E5C2B4594 for ; Tue, 18 Sep 2012 19:46:37 +0100 (BST) Message-ID: <5058C18D.7080808@erg.abdn.ac.uk> Date: Tue, 18 Sep 2012 19:46:37 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: tcmtf@ietf.org References: <005601cd8a70$957ed560$c07c8020$@unizar.es> <009501cd91c3$4bdedf40$e39c9dc0$@unizar.es> In-Reply-To: <009501cd91c3$4bdedf40$e39c9dc0$@unizar.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [tcmtf] Discussing M2M scenario and savings X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk 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, 18 Sep 2012 18:46:41 -0000 A satellite "link" may provide HC, at least some of the ones I have seen do. In this case, the flows can easily be grouped by mac address? Gorry On 13/09/2012 16:20, Jose Saldana wrote: > Hi, Fernando, sorry for the delay (one week, I�m afraid). > > I don�t know who is the one interested on using TCMTF: > > -If you are a costumer, and you have to pay for a satellite link or a > long distance wire, perhaps you are the one interested on using > end-to-end TCMTF, since you will save bandwidth or packets per second or > money. If you have e.g. two offices, one in America and other one in > Europe, you may be interested on placing a device for multiplexing a > number of VoIP calls between them. You have one advantage: the flows > have the same origin and destination, so header compression is effective. > > -If you are the operator of the satellite, you have another problem: you > may have to check every flow, and try to group them. Perhaps it may be > easy, but if you want to save headers, you need flows with the same > origin and destination. > > I think that there are different scenarios, and each �actor� may try to > use TCMTF in the best place: a high number of flows, with small packets, > and sharing the same origin and destination. > > Do you agree? > > Jose > > *De:*tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] *En nombre > de *FERNANDO PASCUAL BLANCO > *Enviado el:* martes, 04 de septiembre de 2012 12:27 > *Para:* tcmtf@ietf.org > *Asunto:* Re: [tcmtf] Discussing M2M scenario and savings > > Hi all, > > Yes, M2M sensor networks are a very good example in order to save > bandwidth in long distance/big latency/low bandwidth links, links were > the cost per bit is high. Do you think network carriers operating this > kind of links (satellite links or long distance wires) would be > interested in apply TCMTF? > > Regards, > > Fernando > > *From:*tcmtf-bounces@ietf.org > [mailto:tcmtf-bounces@ietf.org] > *On Behalf Of *Jose Saldana > *Sent:* martes, 04 de septiembre de 2012 9:41 > *To:* tcmtf@ietf.org > *Cc:* Matteo.Berioli@dlr.de ; > Tomaso.deCola@dlr.de > *Subject:* [tcmtf] Discussing M2M scenario and savings > > Hi again, > > We already discussed some points about the M2M scenario at the beginning > of August. We are currently studying this, and we have built some > figures, in collaboration with people from DLR (Tomaso and Matteo). You > can find the figures here: > > http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_savings.pdf > > http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenario.pdf > > Perhaps we could comment them, in order to discuss this scenario, and we > may find new ones in which TCMTF can be useful. > > Thanks, > > Jose > > ------------------------------------------------------------------------ > > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > nuestra pol�tica de env�o y recepci�n de correo electr�nico en el enlace > situado m�s 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 > > > > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf > From fpb@tid.es Wed Sep 19 01:25:00 2012 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 EA56521F863C for ; Wed, 19 Sep 2012 01:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gxUAD68drcQ for ; Wed, 19 Sep 2012 01:24:59 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 355CA21F8634 for ; Wed, 19 Sep 2012 01:24:58 -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 <0MAL006Q38PLZM@tid.hi.inet> for tcmtf@ietf.org; Wed, 19 Sep 2012 10:24:57 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 07.8B.05494.85189505; Wed, 19 Sep 2012 10:24:57 +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 <0MAL006PX8PKZM@tid.hi.inet> for tcmtf@ietf.org; Wed, 19 Sep 2012 10:24:56 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.229]) by ex10-htcas4-mad.hi.inet ([::1]) with mapi id 14.02.0318.001; Wed, 19 Sep 2012 10:24:02 +0200 Date: Wed, 19 Sep 2012 08:24:01 +0000 From: FERNANDO PASCUAL BLANCO In-reply-to: <5058C18D.7080808@erg.abdn.ac.uk> X-Originating-IP: [10.95.64.115] To: "gorry@erg.abdn.ac.uk" , "tcmtf@ietf.org" Message-id: Content-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [tcmtf] Discussing M2M scenario and savings Thread-index: Ac2KcHryAwwN880YT661jzVtSnJyRwAFrH2wAcrWsYABAqjjgAAg3OaA user-agent: Microsoft-MacOutlook/14.2.3.120616 X-AuditID: 0a5f4e69-b7fc06d000001576-47-5059815839d9 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsXCFe9nqBvZGBlg8G4ru8WuzxsYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8fv8XLaCJaoVv75eYWtgvCzXxcjJISFgIjGvby8ThC0mceHe erYuRi4OIYHtjBI7flwCSwgJ/GSUWHc9HSIxk1Hi+M7/7CAJFgFViS/Pb7KB2GwCWhKn765i AbGFBSwk/m59xgpicwroSew/OQNqg4LEn3OPwWpEBMIkrkzdDBbnFVCTeHP6FFicWcBM4teX v1BxQYkfk+9BxXUker9/Y4awxSWaW29CxbUlnry7ALaLEeiD76fWMEHMt5SYNH8BK4TtJvFw dydYXBTong3vfrNA3CMgsWTPeWYIW1Ti5eN/rBMYxWchOWMWkjNmITljFpIzZiE5YwEj6ypG seKkosz0jJLcxMycdAMjvYxMvcy81JJNjJD4ytzBuHynyiFGAQ5GJR7ehqcRAUKsiWXFlbmH GCU5mJREeavrIgOE+JLyUyozEosz4otKc1KLDzFKcDArifDaZwLleFMSK6tSi/JhUjIcHEoS vD/qgVKCRanpqRVpmTnAJAKTZuLgBGnnAWoXbwBpLy5IzC3OTIfIn2KUlBLnfQjSLACSyCjN g+t9xSgOdKQw7wuQLA8w3cF1vQIayAQ0sOJJGMjAkkSElFQDY8GHLwKas5KcpOcyBmyo3WX8 +rU1h/rDYjW9zTcsF0VtiZgmc12IZ8HvC3e+1E84LBCluG3ykQdc/TwX+PNyZBg3ODh+Xqp+ 64BLgPGcb8sie3bEtNv971HKLly8+Nba4Afnls7cvSRn77f6XQe3Pb80Ryh/ToCrinjF3d9+ N8RnbjP9uMl1orYSS3FGoqEWc1FxIgDpBoriNAMAAA== Subject: Re: [tcmtf] Discussing M2M scenario and savings 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, 19 Sep 2012 08:25:01 -0000 Hi Gorry, In addition of HC (header compression), the multiplexing layer will= save even more resources. In that case and assuming that all the traffic through the link have the same QoS requirements (for example a sensor network), the idea would be to group all the flows through the link (the bottleneck). Regards, Fernando Pascual Blanco Telef=F3nica Global Resources Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F +34913128779 M +34682005168 fpb@tid.es On 18/09/12 20:46, "Gorry Fairhurst" wrote: >A satellite "link" may provide HC, at least some of the ones I have seen >do. In this case, the flows can easily be grouped by mac address? > >Gorry > >On 13/09/2012 16:20, Jose Saldana wrote: >> Hi, Fernando, sorry for the delay (one week, I=B9m afraid). >> >> I don=B9t know who is the one interested on using TCMTF: >> >> -If you are a costumer, and you have to pay for a satellite link or a >> long distance wire, perhaps you are the one interested on using >> end-to-end TCMTF, since you will save bandwidth or packets per second or >> money. If you have e.g. two offices, one in America and other one in >> Europe, you may be interested on placing a device for multiplexing a >> number of VoIP calls between them. You have one advantage: the flows >> have the same origin and destination, so header compression is >>effective. >> >> -If you are the operator of the satellite, you have another problem: you >> may have to check every flow, and try to group them. Perhaps it may be >> easy, but if you want to save headers, you need flows with the same >> origin and destination. >> >> I think that there are different scenarios, and each =B3actor=B2 may try= to >> use TCMTF in the best place: a high number of flows, with small packets, >> and sharing the same origin and destination. >> >> Do you agree? >> >> Jose >> >> *De:*tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] *En nombre >> de *FERNANDO PASCUAL BLANCO >> *Enviado el:* martes, 04 de septiembre de 2012 12:27 >> *Para:* tcmtf@ietf.org >> *Asunto:* Re: [tcmtf] Discussing M2M scenario and savings >> >> Hi all, >> >> Yes, M2M sensor networks are a very good example in order to save >> bandwidth in long distance/big latency/low bandwidth links, links were >> the cost per bit is high. Do you think network carriers operating this >> kind of links (satellite links or long distance wires) would be >> interested in apply TCMTF? >> >> Regards, >> >> Fernando >> >> *From:*tcmtf-bounces@ietf.org >> [mailto:tcmtf-bounces@ietf.org] >> *On Behalf Of *Jose Saldana >> *Sent:* martes, 04 de septiembre de 2012 9:41 >> *To:* tcmtf@ietf.org >> *Cc:* Matteo.Berioli@dlr.de ; >> Tomaso.deCola@dlr.de >> *Subject:* [tcmtf] Discussing M2M scenario and savings >> >> Hi again, >> >> We already discussed some points about the M2M scenario at the beginning >> of August. We are currently studying this, and we have built some >> figures, in collaboration with people from DLR (Tomaso and Matteo). You >> can find the figures here: >> >> http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_savings.pdf >> >> http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenario.pdf >> >> Perhaps we could comment them, in order to discuss this scenario, and we >> may find new ones in which TCMTF can be useful. >> >> Thanks, >> >> Jose >> >> ------------------------------------------------------------------------ >> >> >> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar >> nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en e= l 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 >> >> >> >> _______________________________________________ >> tcmtf mailing list >> tcmtf@ietf.org >> https://www.ietf.org/mailman/listinfo/tcmtf >> > >_______________________________________________ >tcmtf mailing list >tcmtf@ietf.org >https://www.ietf.org/mailman/listinfo/tcmtf ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 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 From gorry@erg.abdn.ac.uk Wed Sep 19 03:37:27 2012 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 C676A21F8739 for ; Wed, 19 Sep 2012 03:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8E1+b2vJTtDv for ; Wed, 19 Sep 2012 03:37:26 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 84C2721F877C for ; Wed, 19 Sep 2012 03:37:26 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 410A82B44CF for ; Wed, 19 Sep 2012 11:37:24 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 19 Sep 2012 11:37:24 +0100 Message-ID: <5e16ec8fc82258693e7d0d5ed433b0e4.squirrel@www.erg.abdn.ac.uk> Date: Wed, 19 Sep 2012 11:37:24 +0100 From: gorry@erg.abdn.ac.uk To: tcmtf@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [tcmtf] Discussing M2M scenario and savings - continuing the thread 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, 19 Sep 2012 10:37:27 -0000 For a point-to-point link carrying traffic destined to a ingle L2 address, I don't see how this helps above the gains of ROHC or some other HC on the link, when possibly combining this with link layer transmission options e.g. methods like PDU-CONCAT in RFC 5163. If you're working over a multi-router network hop, the considerations may be different. Gorry > Hi Gorry, > > I don´t know a lot about link layer HC, but I imagine that it > compress > packet headers (IP-TCP/UDP). If, in addition to that, we group several > small packets into a bigger one (using PPP-Mux and RoHC), don´t you > think > more resources could be saved? > > Regards, > > Fernando Pascual Blanco > Telefónica Global Resources > Network Automation and Dynamization > TECHNOLOGY PEOPLE GROUP > F +34913128779 > M +34682005168 > fpb@tid.es > > > > > On 19/09/12 10:56, "gorry@erg.abdn.ac.uk" wrote: > >>I know there are applications for tunnel compression - but I'm not sure >> I >>understand how this can gain further than for link-layer HC? >> >>Gorry >> >>> Hi Gorry, >>> >>> In addition of HC (header compression), the multiplexing layer >>> will save >>> even more resources. In that case and assuming that all the traffic >>> through the link have the same QoS requirements (for example a sensor >>> network), the idea would be to group all the flows through the link >>> (the >>> bottleneck). >>> >>> Regards, >>> >>> Fernando Pascual Blanco >>> Telefónica Global Resources >>> Network Automation and Dynamization >>> TECHNOLOGY PEOPLE GROUP >>> F +34913128779 >>> M +34682005168 >>> fpb@tid.es >>> >>> >>> >>> >>> On 18/09/12 20:46, "Gorry Fairhurst" wrote: >>> >>>>A satellite "link" may provide HC, at least some of the ones I have >>>> seen >>>>do. In this case, the flows can easily be grouped by mac address? >>>> >>>>Gorry >>>> >>>>On 13/09/2012 16:20, Jose Saldana wrote: >>>>> Hi, Fernando, sorry for the delay (one week, I¹m afraid). >>>>> >>>>> I don¹t know who is the one interested on using TCMTF: >>>>> >>>>> -If you are a costumer, and you have to pay for a satellite link or >>>>> a >>>>> long distance wire, perhaps you are the one interested on using >>>>> end-to-end TCMTF, since you will save bandwidth or packets per >>>>> second >>>>> or >>>>> money. If you have e.g. two offices, one in America and other one in >>>>> Europe, you may be interested on placing a device for multiplexing a >>>>> number of VoIP calls between them. You have one advantage: the flows >>>>> have the same origin and destination, so header compression is >>>>>effective. >>>>> >>>>> -If you are the operator of the satellite, you have another problem: >>>>> you >>>>> may have to check every flow, and try to group them. Perhaps it may >>>>> be >>>>> easy, but if you want to save headers, you need flows with the same >>>>> origin and destination. >>>>> >>>>> I think that there are different scenarios, and each ³actor² may >>>>> try >>>>>to >>>>> use TCMTF in the best place: a high number of flows, with small >>>>> packets, >>>>> and sharing the same origin and destination. >>>>> >>>>> Do you agree? >>>>> >>>>> Jose >>>>> >>>>> *De:*tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] *En >>>>> nombre >>>>> de *FERNANDO PASCUAL BLANCO >>>>> *Enviado el:* martes, 04 de septiembre de 2012 12:27 >>>>> *Para:* tcmtf@ietf.org >>>>> *Asunto:* Re: [tcmtf] Discussing M2M scenario and savings >>>>> >>>>> Hi all, >>>>> >>>>> Yes, M2M sensor networks are a very good example in order to save >>>>> bandwidth in long distance/big latency/low bandwidth links, links >>>>> were >>>>> the cost per bit is high. Do you think network carriers operating >>>>> this >>>>> kind of links (satellite links or long distance wires) would be >>>>> interested in apply TCMTF? >>>>> >>>>> Regards, >>>>> >>>>> Fernando >>>>> >>>>> *From:*tcmtf-bounces@ietf.org >>>>> [mailto:tcmtf-bounces@ietf.org] >>>>> >>>>> *On Behalf Of *Jose Saldana >>>>> *Sent:* martes, 04 de septiembre de 2012 9:41 >>>>> *To:* tcmtf@ietf.org >>>>> *Cc:* Matteo.Berioli@dlr.de ; >>>>> Tomaso.deCola@dlr.de >>>>> *Subject:* [tcmtf] Discussing M2M scenario and savings >>>>> >>>>> Hi again, >>>>> >>>>> We already discussed some points about the M2M scenario at the >>>>> beginning >>>>> of August. We are currently studying this, and we have built some >>>>> figures, in collaboration with people from DLR (Tomaso and Matteo). >>>>>You >>>>> can find the figures here: >>>>> >>>>> http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_savings.pdf >>>>> >>>>> >>>>>http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenario.pdf >>>>> >>>>> Perhaps we could comment them, in order to discuss this scenario, >>>>> and >>>>> we >>>>> may find new ones in which TCMTF can be useful. >>>>> >>>>> Thanks, >>>>> >>>>> Jose >>>>> >>>>> >>>>>----------------------------------------------------------------------- >>>>>- >>>>> >>>>> >>>>> Este mensaje se dirige exclusivamente a su destinatario. Puede >>>>> consultar >>>>> nuestra política de envío y recepción de correo electrónico en >>>>> el >>>>> enlace >>>>> situado más 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 >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> tcmtf mailing list >>>>> tcmtf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcmtf >>>>> >>>> >>>>_______________________________________________ >>>>tcmtf mailing list >>>>tcmtf@ietf.org >>>>https://www.ietf.org/mailman/listinfo/tcmtf >>> >>> >>> ________________________________ >>> >>> Este mensaje se dirige exclusivamente a su destinatario. Puede >>> consultar >>> nuestra política de envío y recepción de correo electrónico en el >>> enlace >>> situado más 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 >>> >> >> > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > nuestra política de envío y recepción de correo electrónico en el > enlace situado más 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 > From fpb@tid.es Wed Sep 19 04:03:02 2012 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 98CFA21F8753 for ; Wed, 19 Sep 2012 04:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.765 X-Spam-Level: X-Spam-Status: No, score=-5.765 tagged_above=-999 required=5 tests=[AWL=0.834, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM1bxt9dT-4n for ; Wed, 19 Sep 2012 04:03:01 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82C3821F873A for ; Wed, 19 Sep 2012 04:02:59 -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 <0MAL00HT4G09XV@tid.hi.inet> for tcmtf@ietf.org; Wed, 19 Sep 2012 13:02:58 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 4F.62.03050.266A9505; Wed, 19 Sep 2012 13:02:58 +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 <0MAL00HW8G0YXV@tid.hi.inet> for tcmtf@ietf.org; Wed, 19 Sep 2012 13:02:58 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.229]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0318.001; Wed, 19 Sep 2012 13:02:04 +0200 Date: Wed, 19 Sep 2012 11:02:03 +0000 From: FERNANDO PASCUAL BLANCO In-reply-to: <5e16ec8fc82258693e7d0d5ed433b0e4.squirrel@www.erg.abdn.ac.uk> X-Originating-IP: [10.95.64.115] To: "gorry@erg.abdn.ac.uk" , "tcmtf@ietf.org" Message-id: Content-id: <8CE192FD6CB5A34ABE51BB52AACBB3D9@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [tcmtf] Discussing M2M scenario and savings - continuing the thread Thread-index: AQHNllKuEVRrf7c0EU+6T/VcCToy35eRgMAA user-agent: Microsoft-MacOutlook/14.2.3.120616 X-AuditID: 0a5f4068-b7f176d000000bea-ef-5059a66239fc X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsXCFe/ApZu0LDLAYOplNYtdnzcwOjB6LFny kymAMYrLJiU1J7MstUjfLoErY8a8R8wFt8IqJnyezNzAuCeki5GTQ0LARGLGrsdMELaYxIV7 69m6GLk4hAQ2MkosPXKSCcL5ySix+VUXK4Qzk1Gibd93VpAWFgFVia2rr4PZbAJaEqfvrmIB sYUFAiQW/tzIDmJzCnhLzD2zkhlihYLEn3OPwWpEBMIkrkzdDLaaV0BN4uPmbYxdjBwczAJm EmsPR0CEBSV+TL7HAhFWl5gyJRckzCwgLtHcepMFwlaUmLaogRHEZhSQlXg3fz4rSLmIQLDE xc28EIuMJC4emgp2gKiAnsSGd79ZII4RkFiy5zzUYaISLx//Y53AKD4L4YZZSG6YhXDDLCQ3 zEJywwJG1lWMYsVJRZnpGSW5iZk56QaGehmZepl5qSWbGCFxlbGDcflOlUOMAhyMSjy8DU8j AoRYE8uKK3MPMUpyMCmJ8rYujQwQ4kvKT6nMSCzOiC8qzUktPsQowcGsJMJrnwmU401JrKxK LcqHSclwcChJ8C4EaRMsSk1PrUjLzAEmD5g0EwcnSDsPUHs+SA1vcUFibnFmOkT+FKOklDhv DUhCACSRUZoH1/uKURzoSGHecpAsDzDNwXW9AhrIBDSw4kkYyMCSRISUVAPjobmds4zmhN3e 9NRyiwHDkT1OM1IN65/vvcV/1O9051I/uSv1MXz7Zix5l9KerLSyY/Glpa4d2/zets3kf+d5 hPmRaA/fL6ZO/2LeaY6qgRVNu5W/mvN+lD3zYpfpOXtd6arJgtYHvNnZ7igdO6iUrhfUVZgs 9PLD4aBdv+z4S6tPr6tvdeVVYinOSDTUYi4qTgQAFWQGHTADAAA= Subject: Re: [tcmtf] Discussing M2M scenario and savings - continuing the thread 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, 19 Sep 2012 11:03:02 -0000 SGkgR29ycnksDQoNCiAgICAgICAgQWJzb2x1dGVseS4gVGhlIHR1bm5lbGluZyBsYXllciB3b3Vs ZCBpbmNyZWFzZSB0aGF0IGJlbmVmaXQgaW4gYQ0KbXVsdGktcm91dGVyIGhvcCBwYXRoLCBiZWlu ZyB0aGUgc2F0ZWxsaXRlLWxpbmsgcGFydCBvZiB0aGlzIHBhdGguDQoNClJlZ2FyZHMsDQoNCkZl cm5hbmRvIFBhc2N1YWwgQmxhbmNvDQpUZWxlZsOzbmljYSBHbG9iYWwgUmVzb3VyY2VzDQpOZXR3 b3JrIEF1dG9tYXRpb24gYW5kIER5bmFtaXphdGlvbg0KVEVDSE5PTE9HWSBQRU9QTEUgR1JPVVAN CkYgKzM0OTEzMTI4Nzc5DQpNICszNDY4MjAwNTE2OA0KZnBiQHRpZC5lcw0KDQoNCg0KDQpPbiAx OS8wOS8xMiAxMjozNywgImdvcnJ5QGVyZy5hYmRuLmFjLnVrIiA8Z29ycnlAZXJnLmFiZG4uYWMu dWs+IHdyb3RlOg0KDQo+DQo+Rm9yIGEgcG9pbnQtdG8tcG9pbnQgbGluayBjYXJyeWluZyB0cmFm ZmljIGRlc3RpbmVkIHRvIGEgaW5nbGUgTDIgYWRkcmVzcywNCj5JIGRvbid0IHNlZSBob3cgdGhp cyBoZWxwcyBhYm92ZSB0aGUgZ2FpbnMgb2YgUk9IQyBvciBzb21lIG90aGVyIEhDIG9uIHRoZQ0K PmxpbmssIHdoZW4gcG9zc2libHkgY29tYmluaW5nIHRoaXMgd2l0aCBsaW5rIGxheWVyIHRyYW5z bWlzc2lvbiBvcHRpb25zDQo+ZS5nLiBtZXRob2RzIGxpa2UgUERVLUNPTkNBVCBpbiBSRkMgNTE2 My4NCj4NCj5JZiB5b3UncmUgd29ya2luZyBvdmVyIGEgbXVsdGktcm91dGVyIG5ldHdvcmsgaG9w LCB0aGUgY29uc2lkZXJhdGlvbnMgbWF5DQo+YmUgZGlmZmVyZW50Lg0KPg0KPkdvcnJ5DQo+DQo+ PiBIaSBHb3JyeSwNCj4+DQo+PiAgICAgICAgIEkgZG9uw4LCtHQga25vdyBhIGxvdCBhYm91dCBs aW5rIGxheWVyIEhDLCBidXQgSSBpbWFnaW5lIHRoYXQgaXQNCj4+IGNvbXByZXNzDQo+PiBwYWNr ZXQgaGVhZGVycyAoSVAtVENQL1VEUCkuIElmLCBpbiBhZGRpdGlvbiB0byB0aGF0LCB3ZSBncm91 cCBzZXZlcmFsDQo+PiBzbWFsbCBwYWNrZXRzIGludG8gYSBiaWdnZXIgb25lICh1c2luZyBQUFAt TXV4IGFuZCBSb0hDKSwgZG9uw4LCtHQgeW91DQo+PiB0aGluaw0KPj4gbW9yZSByZXNvdXJjZXMg Y291bGQgYmUgc2F2ZWQ/DQo+Pg0KPj4gUmVnYXJkcywNCj4+DQo+PiBGZXJuYW5kbyBQYXNjdWFs IEJsYW5jbw0KPj4gVGVsZWbDg8KzbmljYSBHbG9iYWwgUmVzb3VyY2VzDQo+PiBOZXR3b3JrIEF1 dG9tYXRpb24gYW5kIER5bmFtaXphdGlvbg0KPj4gVEVDSE5PTE9HWSBQRU9QTEUgR1JPVVANCj4+ IEYgKzM0OTEzMTI4Nzc5DQo+PiBNICszNDY4MjAwNTE2OA0KPj4gZnBiQHRpZC5lcw0KPj4NCj4+ DQo+Pg0KPj4NCj4+IE9uIDE5LzA5LzEyIDEwOjU2LCAiZ29ycnlAZXJnLmFiZG4uYWMudWsiIDxn b3JyeUBlcmcuYWJkbi5hYy51az4gd3JvdGU6DQo+Pg0KPj4+SSBrbm93IHRoZXJlIGFyZSBhcHBs aWNhdGlvbnMgZm9yIHR1bm5lbCBjb21wcmVzc2lvbiAtIGJ1dCBJJ20gbm90IHN1cmUNCj4+PiBJ DQo+Pj51bmRlcnN0YW5kIGhvdyB0aGlzIGNhbiBnYWluIGZ1cnRoZXIgdGhhbiBmb3IgbGluay1s YXllciBIQz8NCj4+Pg0KPj4+R29ycnkNCj4+Pg0KPj4+PiBIaSBHb3JyeSwNCj4+Pj4NCj4+Pj4g ICAgICAgICBJbiBhZGRpdGlvbiBvZiBIQyAoaGVhZGVyIGNvbXByZXNzaW9uKSwgdGhlIG11bHRp cGxleGluZyBsYXllcg0KPj4+PiB3aWxsIHNhdmUNCj4+Pj4gZXZlbiBtb3JlIHJlc291cmNlcy4g SW4gdGhhdCBjYXNlIGFuZCBhc3N1bWluZyB0aGF0IGFsbCB0aGUgdHJhZmZpYw0KPj4+PiB0aHJv dWdoIHRoZSBsaW5rIGhhdmUgdGhlIHNhbWUgUW9TIHJlcXVpcmVtZW50cyAoZm9yIGV4YW1wbGUg YSBzZW5zb3INCj4+Pj4gbmV0d29yayksIHRoZSBpZGVhIHdvdWxkIGJlIHRvIGdyb3VwIGFsbCB0 aGUgZmxvd3MgdGhyb3VnaCB0aGUgbGluaw0KPj4+PiAodGhlDQo+Pj4+IGJvdHRsZW5lY2spLg0K Pj4+Pg0KPj4+PiBSZWdhcmRzLA0KPj4+Pg0KPj4+PiBGZXJuYW5kbyBQYXNjdWFsIEJsYW5jbw0K Pj4+PiBUZWxlZsODwrNuaWNhIEdsb2JhbCBSZXNvdXJjZXMNCj4+Pj4gTmV0d29yayBBdXRvbWF0 aW9uIGFuZCBEeW5hbWl6YXRpb24NCj4+Pj4gVEVDSE5PTE9HWSBQRU9QTEUgR1JPVVANCj4+Pj4g RiArMzQ5MTMxMjg3NzkNCj4+Pj4gTSArMzQ2ODIwMDUxNjgNCj4+Pj4gZnBiQHRpZC5lcw0KPj4+ Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBPbiAxOC8wOS8xMiAyMDo0NiwgIkdvcnJ5IEZhaXJo dXJzdCIgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPiB3cm90ZToNCj4+Pj4NCj4+Pj4+QSBzYXRlbGxp dGUgImxpbmsiIG1heSBwcm92aWRlIEhDLCBhdCBsZWFzdCBzb21lIG9mIHRoZSBvbmVzIEkgaGF2 ZQ0KPj4+Pj4gc2Vlbg0KPj4+Pj5kby4gSW4gdGhpcyBjYXNlLCB0aGUgZmxvd3MgY2FuIGVhc2ls eSBiZSBncm91cGVkIGJ5IG1hYyBhZGRyZXNzPw0KPj4+Pj4NCj4+Pj4+R29ycnkNCj4+Pj4+DQo+ Pj4+Pk9uIDEzLzA5LzIwMTIgMTY6MjAsIEpvc2UgU2FsZGFuYSB3cm90ZToNCj4+Pj4+PiBIaSwg RmVybmFuZG8sIHNvcnJ5IGZvciB0aGUgZGVsYXkgKG9uZSB3ZWVrLCBJw4LCuW0gYWZyYWlkKS4N Cj4+Pj4+Pg0KPj4+Pj4+IEkgZG9uw4LCuXQga25vdyB3aG8gaXMgdGhlIG9uZSBpbnRlcmVzdGVk IG9uIHVzaW5nIFRDTVRGOg0KPj4+Pj4+DQo+Pj4+Pj4gLUlmIHlvdSBhcmUgYSBjb3N0dW1lciwg YW5kIHlvdSBoYXZlIHRvIHBheSBmb3IgYSBzYXRlbGxpdGUgbGluayBvcg0KPj4+Pj4+IGENCj4+ Pj4+PiBsb25nIGRpc3RhbmNlIHdpcmUsIHBlcmhhcHMgeW91IGFyZSB0aGUgb25lIGludGVyZXN0 ZWQgb24gdXNpbmcNCj4+Pj4+PiBlbmQtdG8tZW5kIFRDTVRGLCBzaW5jZSB5b3Ugd2lsbCBzYXZl IGJhbmR3aWR0aCBvciBwYWNrZXRzIHBlcg0KPj4+Pj4+IHNlY29uZA0KPj4+Pj4+IG9yDQo+Pj4+ Pj4gbW9uZXkuIElmIHlvdSBoYXZlIGUuZy4gdHdvIG9mZmljZXMsIG9uZSBpbiBBbWVyaWNhIGFu ZCBvdGhlciBvbmUgaW4NCj4+Pj4+PiBFdXJvcGUsIHlvdSBtYXkgYmUgaW50ZXJlc3RlZCBvbiBw bGFjaW5nIGEgZGV2aWNlIGZvciBtdWx0aXBsZXhpbmcgYQ0KPj4+Pj4+IG51bWJlciBvZiBWb0lQ IGNhbGxzIGJldHdlZW4gdGhlbS4gWW91IGhhdmUgb25lIGFkdmFudGFnZTogdGhlIGZsb3dzDQo+ Pj4+Pj4gaGF2ZSB0aGUgc2FtZSBvcmlnaW4gYW5kIGRlc3RpbmF0aW9uLCBzbyBoZWFkZXIgY29t cHJlc3Npb24gaXMNCj4+Pj4+PmVmZmVjdGl2ZS4NCj4+Pj4+Pg0KPj4+Pj4+IC1JZiB5b3UgYXJl IHRoZSBvcGVyYXRvciBvZiB0aGUgc2F0ZWxsaXRlLCB5b3UgaGF2ZSBhbm90aGVyIHByb2JsZW06 DQo+Pj4+Pj4geW91DQo+Pj4+Pj4gbWF5IGhhdmUgdG8gY2hlY2sgZXZlcnkgZmxvdywgYW5kIHRy eSB0byBncm91cCB0aGVtLiBQZXJoYXBzIGl0IG1heQ0KPj4+Pj4+IGJlDQo+Pj4+Pj4gZWFzeSwg YnV0IGlmIHlvdSB3YW50IHRvIHNhdmUgaGVhZGVycywgeW91IG5lZWQgZmxvd3Mgd2l0aCB0aGUg c2FtZQ0KPj4+Pj4+IG9yaWdpbiBhbmQgZGVzdGluYXRpb24uDQo+Pj4+Pj4NCj4+Pj4+PiBJIHRo aW5rIHRoYXQgdGhlcmUgYXJlIGRpZmZlcmVudCBzY2VuYXJpb3MsIGFuZCBlYWNoIMOCwrNhY3Rv csOCwrIgbWF5DQo+Pj4+Pj4gdHJ5DQo+Pj4+Pj50bw0KPj4+Pj4+IHVzZSBUQ01URiBpbiB0aGUg YmVzdCBwbGFjZTogYSBoaWdoIG51bWJlciBvZiBmbG93cywgd2l0aCBzbWFsbA0KPj4+Pj4+IHBh Y2tldHMsDQo+Pj4+Pj4gYW5kIHNoYXJpbmcgdGhlIHNhbWUgb3JpZ2luIGFuZCBkZXN0aW5hdGlv bi4NCj4+Pj4+Pg0KPj4+Pj4+IERvIHlvdSBhZ3JlZT8NCj4+Pj4+Pg0KPj4+Pj4+IEpvc2UNCj4+ Pj4+Pg0KPj4+Pj4+ICpEZToqdGNtdGYtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnRjbXRmLWJv dW5jZXNAaWV0Zi5vcmddICpFbg0KPj4+Pj4+IG5vbWJyZQ0KPj4+Pj4+IGRlICpGRVJOQU5ETyBQ QVNDVUFMIEJMQU5DTw0KPj4+Pj4+ICpFbnZpYWRvIGVsOiogbWFydGVzLCAwNCBkZSBzZXB0aWVt YnJlIGRlIDIwMTIgMTI6MjcNCj4+Pj4+PiAqUGFyYToqIHRjbXRmQGlldGYub3JnDQo+Pj4+Pj4g KkFzdW50bzoqIFJlOiBbdGNtdGZdIERpc2N1c3NpbmcgTTJNIHNjZW5hcmlvIGFuZCBzYXZpbmdz DQo+Pj4+Pj4NCj4+Pj4+PiBIaSBhbGwsDQo+Pj4+Pj4NCj4+Pj4+PiBZZXMsIE0yTSBzZW5zb3Ig bmV0d29ya3MgYXJlIGEgdmVyeSBnb29kIGV4YW1wbGUgaW4gb3JkZXIgdG8gc2F2ZQ0KPj4+Pj4+ IGJhbmR3aWR0aCBpbiBsb25nIGRpc3RhbmNlL2JpZyBsYXRlbmN5L2xvdyBiYW5kd2lkdGggbGlu a3MsIGxpbmtzDQo+Pj4+Pj4gd2VyZQ0KPj4+Pj4+IHRoZSBjb3N0IHBlciBiaXQgaXMgaGlnaC4g RG8geW91IHRoaW5rIG5ldHdvcmsgY2FycmllcnMgb3BlcmF0aW5nDQo+Pj4+Pj4gdGhpcw0KPj4+ Pj4+IGtpbmQgb2YgbGlua3MgKHNhdGVsbGl0ZSBsaW5rcyBvciBsb25nIGRpc3RhbmNlIHdpcmVz KSB3b3VsZCBiZQ0KPj4+Pj4+IGludGVyZXN0ZWQgaW4gYXBwbHkgVENNVEY/DQo+Pj4+Pj4NCj4+ Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+DQo+Pj4+Pj4gRmVybmFuZG8NCj4+Pj4+Pg0KPj4+Pj4+ICpG cm9tOip0Y210Zi1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86dGNtdGYtYm91bmNlc0BpZXRmLm9y Zz4NCj4+Pj4+PiBbbWFpbHRvOnRjbXRmLWJvdW5jZXNAaWV0Zi5vcmddDQo+Pj4+Pj4gPG1haWx0 bzpbbWFpbHRvOnRjbXRmLWJvdW5jZXNAaWV0Zi5vcmddPg0KPj4+Pj4+ICpPbiBCZWhhbGYgT2Yg Kkpvc2UgU2FsZGFuYQ0KPj4+Pj4+ICpTZW50OiogbWFydGVzLCAwNCBkZSBzZXB0aWVtYnJlIGRl IDIwMTIgOTo0MQ0KPj4+Pj4+ICpUbzoqIHRjbXRmQGlldGYub3JnIDxtYWlsdG86dGNtdGZAaWV0 Zi5vcmc+DQo+Pj4+Pj4gKkNjOiogTWF0dGVvLkJlcmlvbGlAZGxyLmRlIDxtYWlsdG86TWF0dGVv LkJlcmlvbGlAZGxyLmRlPjsNCj4+Pj4+PiBUb21hc28uZGVDb2xhQGRsci5kZSA8bWFpbHRvOlRv bWFzby5kZUNvbGFAZGxyLmRlPg0KPj4+Pj4+ICpTdWJqZWN0OiogW3RjbXRmXSBEaXNjdXNzaW5n IE0yTSBzY2VuYXJpbyBhbmQgc2F2aW5ncw0KPj4+Pj4+DQo+Pj4+Pj4gSGkgYWdhaW4sDQo+Pj4+ Pj4NCj4+Pj4+PiBXZSBhbHJlYWR5IGRpc2N1c3NlZCBzb21lIHBvaW50cyBhYm91dCB0aGUgTTJN IHNjZW5hcmlvIGF0IHRoZQ0KPj4+Pj4+IGJlZ2lubmluZw0KPj4+Pj4+IG9mIEF1Z3VzdC4gV2Ug YXJlIGN1cnJlbnRseSBzdHVkeWluZyB0aGlzLCBhbmQgd2UgaGF2ZSBidWlsdCBzb21lDQo+Pj4+ Pj4gZmlndXJlcywgaW4gY29sbGFib3JhdGlvbiB3aXRoIHBlb3BsZSBmcm9tIERMUiAoVG9tYXNv IGFuZCBNYXR0ZW8pLg0KPj4+Pj4+WW91DQo+Pj4+Pj4gY2FuIGZpbmQgdGhlIGZpZ3VyZXMgaGVy ZToNCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj5odHRwOi8vZGllYy51bml6YXIuZXMvfmpzYWxkYW5h L3BlcnNvbmFsL3RjbXRmX2ZpZ3VyZXMvbTJtX3NhdmluZ3MucGQNCj4+Pj4+PmYNCj4+Pj4+Pg0K Pj4+Pj4+DQo+Pj4+Pj5odHRwOi8vZGllYy51bml6YXIuZXMvfmpzYWxkYW5hL3BlcnNvbmFsL3Rj bXRmX2ZpZ3VyZXMvbTJtX3NjZW5hcmlvLnANCj4+Pj4+PmRmDQo+Pj4+Pj4NCj4+Pj4+PiBQZXJo YXBzIHdlIGNvdWxkIGNvbW1lbnQgdGhlbSwgaW4gb3JkZXIgdG8gZGlzY3VzcyB0aGlzIHNjZW5h cmlvLA0KPj4+Pj4+IGFuZA0KPj4+Pj4+IHdlDQo+Pj4+Pj4gbWF5IGZpbmQgbmV3IG9uZXMgaW4g d2hpY2ggVENNVEYgY2FuIGJlIHVzZWZ1bC4NCj4+Pj4+Pg0KPj4+Pj4+IFRoYW5rcywNCj4+Pj4+ Pg0KPj4+Pj4+IEpvc2UNCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+ Pi0tDQo+Pj4+Pj4tDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IEVzdGUgbWVuc2FqZSBzZSBkaXJp Z2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlDQo+Pj4+Pj4gY29uc3Vs dGFyDQo+Pj4+Pj4gbnVlc3RyYSBwb2zDg8KtdGljYSBkZSBlbnbDg8KtbyB5IHJlY2VwY2nDg8Kz biBkZSBjb3JyZW8gZWxlY3Ryw4PCs25pY28gZW4NCj4+Pj4+PiBlbA0KPj4+Pj4+IGVubGFjZQ0K Pj4+Pj4+IHNpdHVhZG8gbcODwqFzIGFiYWpvLg0KPj4+Pj4+IFRoaXMgbWVzc2FnZSBpcyBpbnRl bmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kDQo+Pj4+Pj4g YW5kDQo+Pj4+Pj4gcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBv dXQgYXQ6DQo+Pj4+Pj4gaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFz cHgNCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IHRjbXRmIG1haWxpbmcgbGlzdA0KPj4+ Pj4+IHRjbXRmQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90Y210Zg0KPj4+Pj4+DQo+Pj4+Pg0KPj4+Pj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj50Y210ZiBtYWlsaW5nIGxpc3QNCj4+Pj4+ dGNtdGZAaWV0Zi5vcmcNCj4+Pj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90Y210Zg0KPj4+Pg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+Pg0KPj4+PiBFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3Ug ZGVzdGluYXRhcmlvLiBQdWVkZQ0KPj4+PiBjb25zdWx0YXINCj4+Pj4gbnVlc3RyYSBwb2zDg8Kt dGljYSBkZSBlbnbDg8KtbyB5IHJlY2VwY2nDg8KzbiBkZSBjb3JyZW8gZWxlY3Ryw4PCs25pY28g ZW4gZWwNCj4+Pj4gZW5sYWNlDQo+Pj4+IHNpdHVhZG8gbcODwqFzIGFiYWpvLg0KPj4+PiBUaGlz IG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9u bHkgc2VuZA0KPj4+PiBhbmQNCj4+Pj4gcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhl IHRlcm1zIHNldCBvdXQgYXQ6DQo+Pj4+IGh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlz Y2xhaW1lci5hc3B4DQo+Pj4+DQo+Pj4NCj4+Pg0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4NCj4+IEVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZh bWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhcg0KPj4gbnVlc3RyYSBwb2zD g8KtdGljYSBkZSBlbnbDg8KtbyB5IHJlY2VwY2nDg8KzbiBkZSBjb3JyZW8gZWxlY3Ryw4PCs25p Y28gZW4gZWwNCj4+IGVubGFjZSBzaXR1YWRvIG3Dg8KhcyBhYmFqby4NCj4+IFRoaXMgbWVzc2Fn ZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5k IGFuZA0KPj4gcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQg YXQ6DQo+PiBodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0KPj4N Cj4NCj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPnRjbXRmIG1haWxpbmcgbGlzdA0KPnRjbXRmQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y210Zg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBk ZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8g eSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8g bcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRz IGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBv ZiB0aGUgdGVybXMgc2V0IG91dCBhdDoNCmh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlz Y2xhaW1lci5hc3B4DQo= From jsaldana@unizar.es Thu Sep 20 09:20:42 2012 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 C19A121F87EA for ; Thu, 20 Sep 2012 09:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.224 X-Spam-Level: X-Spam-Status: No, score=-4.224 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWZVb0-grefq for ; Thu, 20 Sep 2012 09:20:41 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4134321F87E9 for ; Thu, 20 Sep 2012 09:20:39 -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 q8KGKWd0008162; Thu, 20 Sep 2012 18:20:32 +0200 From: "Jose Saldana" To: "'FERNANDO PASCUAL BLANCO'" , , References: <5e16ec8fc82258693e7d0d5ed433b0e4.squirrel@www.erg.abdn.ac.uk> In-Reply-To: Date: Thu, 20 Sep 2012 18:20:35 +0200 Organization: Universidad de Zaragoza Message-ID: <005401cd974b$ddd88b70$9989a250$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01CD975C.A1641A90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKkahCGuVMIppcZw/Qjh/z2pOklMJXlwpEw Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: Re: [tcmtf] Discussing M2M scenario and savings - continuing the thread 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 Sep 2012 16:20:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0055_01CD975C.A1641A90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So, do you think the figure should be modified? Perhaps it is currently = confusing, since it seems that RFC 5163 is the best solution. Perhaps a = network should be included between the demux and the data center? Or = between the antenna and the demux? Will this be a real case? I don't = know if in the right side it is possible to find other networks. =20 I am talking about this figure: http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenario.pdf =20 Thanks, =20 Jose =20 -----Mensaje original----- De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de = FERNANDO PASCUAL BLANCO Enviado el: mi=C3=A9rcoles, 19 de septiembre de 2012 13:02 Para: gorry@erg.abdn.ac.uk; tcmtf@ietf.org Asunto: Re: [tcmtf] Discussing M2M scenario and savings - continuing the = thread =20 Hi Gorry, =20 Absolutely. The tunneling layer would increase that benefit in a = multi-router hop path, being the satellite-link part of this path. =20 Regards, =20 Fernando Pascual Blanco Telef=C3=B3nica Global Resources Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F +34913128779 M +34682005168 fpb@tid.es =20 =20 =20 =20 On 19/09/12 12:37, " gorry@erg.abdn.ac.uk" = < gorry@erg.abdn.ac.uk> wrote: =20 >=20 >For a point-to-point link carrying traffic destined to a ingle L2=20 >address, I don't see how this helps above the gains of ROHC or some=20 >other HC on the link, when possibly combining this with link layer=20 >transmission options e.g. methods like PDU-CONCAT in RFC 5163. >=20 >If you're working over a multi-router network hop, the considerations=20 >may be different. >=20 >Gorry >=20 >> Hi Gorry, >>=20 >> I don=C3=82=C2=B4t know a lot about link layer HC, but I = imagine that=20 >> it compress packet headers (IP-TCP/UDP). If, in addition to that, we=20 >> group several small packets into a bigger one (using PPP-Mux and=20 >> RoHC), don=C3=82=C2=B4t you think more resources could be saved? >>=20 >> Regards, >>=20 >> Fernando Pascual Blanco >> Telef=C3=83=C2=B3nica Global Resources >> Network Automation and Dynamization >> TECHNOLOGY PEOPLE GROUP >> F +34913128779 >> M +34682005168 >> fpb@tid.es >>=20 >>=20 >>=20 >>=20 >> On 19/09/12 10:56, " = gorry@erg.abdn.ac.uk" < = gorry@erg.abdn.ac.uk> wrote: >>=20 >>>I know there are applications for tunnel compression - but I'm not=20 >>>sure I understand how this can gain further than for link-layer HC? >>>=20 >>>Gorry >>>=20 >>>> Hi Gorry, >>>>=20 >>>> In addition of HC (header compression), the multiplexing=20 >>>> layer will save even more resources. In that case and assuming that = >>>> all the traffic through the link have the same QoS requirements=20 >>>> (for example a sensor network), the idea would be to group all the=20 >>>> flows through the link (the bottleneck). >>>>=20 >>>> Regards, >>>>=20 >>>> Fernando Pascual Blanco >>>> Telef=C3=83=C2=B3nica Global Resources >>>> Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F=20 >>>> +34913128779 M +34682005168 fpb@tid.es >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 18/09/12 20:46, "Gorry Fairhurst" < = gorry@erg.abdn.ac.uk> wrote: >>>>=20 >>>>>A satellite "link" may provide HC, at least some of the ones I have = =20 >>>>>seen do. In this case, the flows can easily be grouped by mac=20 >>>>>address? >>>>>=20 >>>>>Gorry >>>>>=20 >>>>>On 13/09/2012 16:20, Jose Saldana wrote: >>>>>> Hi, Fernando, sorry for the delay (one week, I=C3=82=C2=B9m = afraid). >>>>>>=20 >>>>>> I don=C3=82=C2=B9t know who is the one interested on using TCMTF: >>>>>>=20 >>>>>> -If you are a costumer, and you have to pay for a satellite link=20 >>>>>>or a long distance wire, perhaps you are the one interested on=20 >>>>>>using end-to-end TCMTF, since you will save bandwidth or packets=20 >>>>>>per second or money. If you have e.g. two offices, one in=20 >>>>>>America and other one in Europe, you may be interested on placing = >>>>>>a device for multiplexing a number of VoIP calls between them.=20 >>>>>>You have one advantage: the flows have the same origin and=20 >>>>>>destination, so header compression is effective. >>>>>>=20 >>>>>> -If you are the operator of the satellite, you have another = problem: >>>>>> you >>>>>> may have to check every flow, and try to group them. Perhaps it=20 >>>>>> may be easy, but if you want to save headers, you need flows with = >>>>>> the same origin and destination. >>>>>>=20 >>>>>> I think that there are different scenarios, and each = =C3=82=C2=B3actor=C3=82=C2=B2=20 >>>>>>may try to use TCMTF in the best place: a high number of flows,=20 >>>>>>with small packets, and sharing the same origin and destination. >>>>>>=20 >>>>>> Do you agree? >>>>>>=20 >>>>>> Jose >>>>>>=20 >>>>>> *De:*tcmtf-bounces@ietf.org = [mailto:tcmtf-bounces@ietf.org] = *En=20 >>>>>> nombre de *FERNANDO PASCUAL BLANCO *Enviado el:* martes, 04 de=20 >>>>>> septiembre de 2012 12:27 >>>>>> *Para:* tcmtf@ietf.org >>>>>> *Asunto:* Re: [tcmtf] Discussing M2M scenario and savings >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> Yes, M2M sensor networks are a very good example in order to save = >>>>>> bandwidth in long distance/big latency/low bandwidth links, links = >>>>>> were the cost per bit is high. Do you think network carriers=20 >>>>>> operating this kind of links (satellite links or long distance=20 >>>>>> wires) would be interested in apply TCMTF? >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Fernando >>>>>>=20 >>>>>> *From:*tcmtf-bounces@ietf.org < = mailto:tcmtf-bounces@ietf.org>=20 >>>>>> = [mailto:tcmtf-bounces@ietf.org]=20 >>>>>> < = mailto:[mailto:tcmtf-bounces@ietf.org]> >>>>>> *On Behalf Of *Jose Saldana >>>>>> *Sent:* martes, 04 de septiembre de 2012 9:41 >>>>>> *To:* tcmtf@ietf.org < = mailto:tcmtf@ietf.org> >>>>>> *Cc:* Matteo.Berioli@dlr.de < = mailto:Matteo.Berioli@dlr.de>;=20 >>>>>> Tomaso.deCola@dlr.de < = mailto:Tomaso.deCola@dlr.de> >>>>>> *Subject:* [tcmtf] Discussing M2M scenario and savings >>>>>>=20 >>>>>> Hi again, >>>>>>=20 >>>>>> We already discussed some points about the M2M scenario at the =20 >>>>>>beginning of August. We are currently studying this, and we have=20 >>>>>>built some figures, in collaboration with people from DLR (Tomaso = >>>>>>and Matteo). >>>>>>You >>>>>> can find the figures here: >>>>>>=20 >>>>>>=20 >>>>>> = = http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_savings >>>>>>.pd >>>>>>f >>>>>>=20 >>>>>>=20 >>>>>> = = http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenari >>>>>>o.p >>>>>>df >>>>>>=20 >>>>>> Perhaps we could comment them, in order to discuss this scenario, = >>>>>> and we may find new ones in which TCMTF can be useful. >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Jose >>>>>>=20 >>>>>>=20 >>>>>>------------------------------------------------------------------ >>>>>>--- >>>>>>-- >>>>>>- >>>>>>=20 >>>>>>=20 >>>>>> Este mensaje se dirige exclusivamente a su destinatario. Puede=20 >>>>>> consultar nuestra pol=C3=83=C2=ADtica de env=C3=83=C2=ADo y = recepci=C3=83=C2=B3n de correo=20 >>>>>> electr=C3=83=C2=B3nico en el enlace situado m=C3=83=C2=A1s abajo. >>>>>> This message is intended exclusively for its addressee. We only=20 >>>>>> send and receive email on the basis of the terms set out at: >>>>>> = http://www.tid.es/ES/PAGINAS/disclaimer.aspx >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> tcmtf mailing list >>>>>> tcmtf@ietf.org >>>>>> = https://www.ietf.org/mailman/listinfo/tcmtf >>>>>>=20 >>>>>=20 >>>>>_______________________________________________ >>>>>tcmtf mailing list >>>>> tcmtf@ietf.org >>>>> = https://www.ietf.org/mailman/listinfo/tcmtf >>>>=20 >>>>=20 >>>> ________________________________ >>>>=20 >>>> Este mensaje se dirige exclusivamente a su destinatario. Puede=20 >>>> consultar nuestra pol=C3=83=C2=ADtica de env=C3=83=C2=ADo y = recepci=C3=83=C2=B3n de correo=20 >>>> electr=C3=83=C2=B3nico en el enlace situado m=C3=83=C2=A1s abajo. >>>> This message is intended exclusively for its addressee. We only=20 >>>> send and receive email on the basis of the terms set out at: >>>> = http://www.tid.es/ES/PAGINAS/disclaimer.aspx >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >> ________________________________ >>=20 >> Este mensaje se dirige exclusivamente a su destinatario. Puede=20 >> consultar nuestra pol=C3=83=C2=ADtica de env=C3=83=C2=ADo y = recepci=C3=83=C2=B3n de correo=20 >> electr=C3=83=C2=B3nico en el enlace situado m=C3=83=C2=A1s abajo. >> This message is intended exclusively for its addressee. We only send=20 >> and receive email on the basis of the terms set out at: >> = http://www.tid.es/ES/PAGINAS/disclaimer.aspx >>=20 >=20 >=20 >=20 >_______________________________________________ >tcmtf mailing list > tcmtf@ietf.org > = https://www.ietf.org/mailman/listinfo/tcmtf =20 =20 ________________________________ =20 Este mensaje se dirige exclusivamente a su destinatario. Puede consultar = nuestra pol=C3=ADtica de env=C3=ADo y recepci=C3=B3n de correo = electr=C3=B3nico en el enlace situado m=C3=A1s 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 _______________________________________________ tcmtf mailing list tcmtf@ietf.org = https://www.ietf.org/mailman/listinfo/tcmtf ------=_NextPart_000_0055_01CD975C.A1641A90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, do you think the figure should be modified? Perhaps it = is currently confusing, since it seems that RFC 5163 is the best = solution. Perhaps a network should be included between the demux and the = data center? Or between the antenna and the demux? Will this be a real = case? I don't know if in the right side it is possible to find other = networks.

I am talking about this figure:
http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenar= io.pdf

Thanks,

Jose

-----Mensaje = original-----
De: tcmtf-bounces@ietf.org = [mailto:tcmtf-bounces@ietf.org] En nombre de FERNANDO PASCUAL = BLANCO
Enviado el: mi=C3=A9rcoles, 19 de septiembre de 2012 = 13:02
Para: gorry@erg.abdn.ac.uk; tcmtf@ietf.org
Asunto: Re: = [tcmtf] Discussing M2M scenario and savings - continuing the = thread

Hi Gorry,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Absolutely. The tunneling layer would increase that benefit in a = multi-router hop path, being the satellite-link part of this = path.

Regards,

Fernando Pascual Blanco
Telef=C3=B3nica Global Resources
Network Automation and = Dynamization
TECHNOLOGY PEOPLE = GROUP
F = +34913128779
M = +34682005168
fpb@tid.es

On = 19/09/12 12:37, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk> wrote:

>
>For a point-to-point link carrying traffic = destined to a ingle L2
>address, I don't see how this helps above the = gains of ROHC or some
>other = HC on the link, when possibly combining this with link layer =
>transmission options e.g. = methods like PDU-CONCAT in RFC 5163.
>
>If you're working over a multi-router network = hop, the considerations
>may = be different.
>
>Gorry
>
>> Hi Gorry,
>>
>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 I don=C3=82=C2=B4t know a lot about link layer HC, but I imagine = that
>> it compress packet = headers (IP-TCP/UDP). If, in addition to that, we
>> group several small packets into a bigger = one (using PPP-Mux and
>> = RoHC), don=C3=82=C2=B4t you think more resources could be = saved?
>>
>> Regards,
>>
>> Fernando Pascual Blanco
>> Telef=C3=83=C2=B3nica Global = Resources
>> Network = Automation and Dynamization
>> TECHNOLOGY PEOPLE GROUP
>> F +34913128779
>> M +34682005168
>> fpb@tid.es
>>
>>
>>
>>
>> On 19/09/12 10:56, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk> wrote:
>>
>>>I know there are applications for = tunnel compression - but I'm not
>>>sure=C2=A0 I understand how this can = gain further than for link-layer HC?
>>>
>>>Gorry
>>>
>>>> Hi Gorry,
>>>>
>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 In addition of HC (header compression), the multiplexing =
>>>> layer will save = even more resources. In that case and assuming that
>>>> all the traffic through the link = have the same QoS requirements
>>>> (for example a sensor network), = the idea would be to group all the
>>>> flows through the link (the = bottleneck).
>>>>
>>>> Regards,
>>>>
>>>> Fernando Pascual = Blanco
>>>> = Telef=C3=83=C2=B3nica Global Resources
>>>> Network Automation and = Dynamization TECHNOLOGY PEOPLE GROUP F
>>>> +34913128779 M +34682005168 fpb@tid.es
>>>>
>>>>
>>>>
>>>>
>>>> On 18/09/12 20:46, "Gorry = Fairhurst" <gorry@erg.abdn.ac.uk> wrote:
>>>>
>>>>>A satellite "link" = may provide HC, at least some of the ones I have=C2=A0
>>>>>seen do. In this case, the = flows can easily be grouped by mac
>>>>>address?
>>>>>
>>>>>Gorry
>>>>>
>>>>>On 13/09/2012 16:20, Jose = Saldana wrote:
>>>>>> Hi, Fernando, sorry for = the delay (one week, I=C3=82=C2=B9m afraid).
>>>>>>
>>>>>> I don=C3=82=C2=B9t know = who is the one interested on using TCMTF:
>>>>>>
>>>>>> -If you are a costumer, = and you have to pay for a satellite link
>>>>>>or=C2=A0 a=C2=A0 long = distance wire, perhaps you are the one interested on
>>>>>>using=C2=A0 end-to-end = TCMTF, since you will save bandwidth or packets
>>>>>>per=C2=A0 second=C2=A0 = or=C2=A0 money. If you have e.g. two offices, one in
>>>>>>America and other one = in=C2=A0 Europe, you may be interested on placing
>>>>>>a device for multiplexing = a=C2=A0 number of VoIP calls between them.
>>>>>>You have one advantage: the = flows=C2=A0 have the same origin and
>>>>>>destination, so header = compression is effective.
>>>>>>
>>>>>> -If you are the operator = of the satellite, you have another problem:
>>>>>> you
>>>>>> may have to check every = flow, and try to group them. Perhaps it
>>>>>> may be easy, but if you = want to save headers, you need flows with
>>>>>> the same origin and = destination.
>>>>>>
>>>>>> I think that there are = different scenarios, and each =C3=82=C2=B3actor=C3=82=C2=B2 =
>>>>>>may=C2=A0 = try to=C2=A0 use TCMTF in the best place: a high number of flows, =
>>>>>>with = small=C2=A0 packets,=C2=A0 and sharing the same origin and = destination.
>>>>>>
>>>>>> Do you = agree?
>>>>>>
>>>>>> Jose
>>>>>>
>>>>>> = *De:*tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@iet= f.org] *En
>>>>>> nombre de *FERNANDO = PASCUAL BLANCO *Enviado el:* martes, 04 de
>>>>>> septiembre de 2012 = 12:27
>>>>>> = *Para:* tcmtf@ietf.org=
>>>>>> = *Asunto:* Re: [tcmtf] Discussing M2M scenario and = savings
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Yes, M2M sensor networks = are a very good example in order to save
>>>>>> bandwidth in long = distance/big latency/low bandwidth links, links
>>>>>> were the cost per bit is = high. Do you think network carriers
>>>>>> operating this kind of = links (satellite links or long distance
>>>>>> wires) would be interested = in apply TCMTF?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Fernando
>>>>>>
>>>>>> = *From:*tcmtf-bounces@ietf.org <mailto:tcmtf-bounces@ietf= .org>
>>>>>> [mailto:tcmtf-bounces@iet= f.org]
>>>>>> <mailto:[mailto:tcmtf-boun= ces@ietf.org]>
>>>>>> *On Behalf Of *Jose = Saldana
>>>>>> = *Sent:* martes, 04 de septiembre de 2012 9:41
>>>>>> *To:* tcmtf@ietf.org= <mailto:tcmtf@ietf.org>
>>>>>> *Cc:* Matteo.Berioli@dlr.de <mailto:Matteo.Berioli@dlr= .de>;
>>>>>> Tomaso.deCola@dlr.de <mailto:Tomaso.deCola@dlr.= de>
>>>>>> *Subject:* [tcmtf] = Discussing M2M scenario and savings
>>>>>>
>>>>>> Hi again,
>>>>>>
>>>>>> We already discussed some = points about the M2M scenario at the=C2=A0
>>>>>>beginning=C2=A0 of August. = We are currently studying this, and we have
>>>>>>built some=C2=A0 figures, = in collaboration with people from DLR (Tomaso
>>>>>>and = Matteo).
>>>>>>You
>>>>>> can find the figures = here:
>>>>>>
>>>>>>
>>>>>>http://diec.unizar.es/~js= aldana/personal/tcmtf_figures/m2m_savings
>>>>>>.pd
>>>>>>f
>>>>>>
>>>>>>
>>>>>>http://diec.unizar.es/~js= aldana/personal/tcmtf_figures/m2m_scenari
>>>>>>o.p
>>>>>>df
>>>>>>
>>>>>> Perhaps we could comment = them, in order to discuss this scenario,
>>>>>> and we may find new ones = in which TCMTF can be useful.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jose
>>>>>>
>>>>>>
>>>>>>----------------------------= --------------------------------------
>>>>>>---
>>>>>>--
>>>>>>-
>>>>>>
>>>>>>
>>>>>> Este mensaje se dirige = exclusivamente a su destinatario. Puede
>>>>>> consultar nuestra = pol=C3=83=C2=ADtica de env=C3=83=C2=ADo y recepci=C3=83=C2=B3n de correo =
>>>>>> = electr=C3=83=C2=B3nico en el enlace situado m=C3=83=C2=A1s = 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/PAGI= NAS/disclaimer.aspx
>>>>>>
>>>>>>
>>>>>>
>>>>>> = _______________________________________________
>>>>>> tcmtf mailing = list
>>>>>> tcmtf@ietf.org=
>>>>>> https://www.ietf.org/mail= man/listinfo/tcmtf
>>>>>>
>>>>>
>>>>>________________________________= _______________
>>>>>tcmtf mailing = list
>>>>>tcmtf@ietf.org=
>>>>>https://www.ietf.org/mail= man/listinfo/tcmtf
>>>>
>>>>
>>>> = ________________________________
>>>>
>>>> Este mensaje se dirige = exclusivamente a su destinatario. Puede
>>>> consultar nuestra = pol=C3=83=C2=ADtica de env=C3=83=C2=ADo y recepci=C3=83=C2=B3n de correo =
>>>> = electr=C3=83=C2=B3nico en el enlace situado m=C3=83=C2=A1s = 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/PAGI= NAS/disclaimer.aspx
>>>>
>>>
>>>
>>
>>
>> = ________________________________
>>
>> Este mensaje se dirige exclusivamente a su = destinatario. Puede
>> = consultar nuestra pol=C3=83=C2=ADtica de env=C3=83=C2=ADo y = recepci=C3=83=C2=B3n de correo
>> electr=C3=83=C2=B3nico en el enlace = situado m=C3=83=C2=A1s 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/PAGI= NAS/disclaimer.aspx
>>
>
>
>
>_______________________________________________<= o:p>
>tcmtf mailing = list
>tcmtf@ietf.org=
>https://www.ietf.org/mail= man/listinfo/tcmtf

________________________________

Este = mensaje se dirige exclusivamente a su destinatario. Puede consultar = nuestra pol=C3=ADtica de env=C3=ADo y recepci=C3=B3n de correo = electr=C3=B3nico en el enlace situado m=C3=A1s 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/PAGI= NAS/disclaimer.aspx
_______________________________________________=
tcmtf mailing list
tcmtf@ietf.org=
https://www.ietf.org/mail= man/listinfo/tcmtf
------=_NextPart_000_0055_01CD975C.A1641A90-- From fpb@tid.es Fri Sep 21 00:48:07 2012 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 727CA21F84EA for ; Fri, 21 Sep 2012 00:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.973 X-Spam-Level: X-Spam-Status: No, score=-5.973 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+-vaXCq8dDZ for ; Fri, 21 Sep 2012 00:48:05 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7361E21F84D9 for ; Fri, 21 Sep 2012 00:48:00 -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 <0MAO00IP1WBXTU@tid.hi.inet> for tcmtf@ietf.org; Fri, 21 Sep 2012 09:47:59 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 55.11.03050.EAB1C505; Fri, 21 Sep 2012 09:47:58 +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 <0MAO00IQXWBYTU@tid.hi.inet> for tcmtf@ietf.org; Fri, 21 Sep 2012 09:47:58 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.87]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0318.001; Fri, 21 Sep 2012 09:47:02 +0200 Date: Fri, 21 Sep 2012 07:47:01 +0000 From: FERNANDO PASCUAL BLANCO In-reply-to: <005401cd974b$ddd88b70$9989a250$@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_xWWPZSvqhesRFS4EfIR3zA)" Content-language: en-US Accept-Language: en-US, es-ES Thread-topic: [tcmtf] Discussing M2M scenario and savings - continuing the thread Thread-index: AQHNl81Joku1fR4ujUGBzUJHEVk0cQ== user-agent: Microsoft-MacOutlook/14.2.3.120616 X-AuditID: 0a5f4068-b7f176d000000bea-82-505c1bae4700 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLKsWRmVeSWpSXmKPExsXCFe/ApbtOOibAYNdVLYtdnzcwOjB6LFny kymAMYrLJiU1J7MstUjfLoEr48C2rWwFc+YwV/y50cTSwLh3InMXIyeHhICJxN6Jq5kgbDGJ C/fWs3UxcnEICWxklPhwqJEFwvnJKLHs+z8mCGcao8TM7XMZQVpYBFQlpn56wgZiswloSZy+ u4oFxBYWCJBY+HMjO4jNKWAhcWjvEjaIFQoSf849BqsRAarZ3XIAzOYV8JbYdv8mG4QtKPFj 8j2wOLNArsTeo/PZIWxxiebWm2BxRgFZiXfz57N2MXIAzQmWuLiZF2KknsTtJ0/AykWB7A3v frNArBWQWLLnPNTHohIvH/9jncAoOgvJtllIts1Csm0W0AZmAU2J9bv0IcKKElO6H0KVaEi0 zpnLDlFiJjHtkzWykgWMHKsYxYqTijLTM0pyEzNz0g0M9TIy9TLzUks2MULiLmMH4/KdKocY BTgYlXh4M+9GBQixJpYVV+YeYpTkYFIS5RURjwkQ4kvKT6nMSCzOiC8qzUktPsQowcGsJML7 KCY6QIg3JbGyKrUoHyYlw8GhJMH7QAqoTbAoNT21Ii0zB5hcYNJMHJwg7TxA7QdAaniLCxJz izPTIfKnGCWlxHm5gMlJSAAkkVGaB9f7ilEc6Ehh3nMgbTzANAjX9QpoIBPQwDfXo0AGliQi pKQaGI/dWhKru1z9Sp8Wv3Zf6d0IG5fLd95qKs5IM+NJqtU6+Ha+689NaQYBK7KuTtgwV26b eWmKxHYHIW7Fyb+C5wQ7FXzevrwpJC71WbVhEp+NikrJxdK1T3etOcZ7oo05cf59q8mTONOd wjOlP57oi3GYxeLvHH1XcVXyhBthM7dNyg5w1tCOUmIpzkg01GIuKk4EALjNr4hAAwAA Subject: Re: [tcmtf] Discussing M2M scenario and savings - continuing the thread 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: Fri, 21 Sep 2012 07:48:07 -0000 --Boundary_(ID_xWWPZSvqhesRFS4EfIR3zA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 SGkgSm9zZSwNCg0KSSB0aGluayB0aGVyZSB3aWxsIGJlIHNldmVyYWwgbGF5ZXIgMyBob3BzIGJl dHdlZW4gdGhlIGRlbXV4IGFuZCB0aGUgZGF0YSBjZW50ZXIgYW5kIG5vdCBpbiB0aGUgb3RoZXIg c2lkZS4NCg0KUmVnYXJkcywNCg0KRmVybmFuZG8gUGFzY3VhbCBCbGFuY28NClRlbGVmw7NuaWNh IEdsb2JhbCBSZXNvdXJjZXMNCk5ldHdvcmsgQXV0b21hdGlvbiBhbmQgRHluYW1pemF0aW9uDQpU RUNITk9MT0dZIFBFT1BMRSBHUk9VUA0KRiArMzQ5MTMxMjg3NzkNCk0gKzM0NjgyMDA1MTY4DQpm cGJAdGlkLmVzDQoNCkZyb206ICJqc2FsZGFuYUB1bml6YXIuZXM8bWFpbHRvOmpzYWxkYW5hQHVu aXphci5lcz4iIDxqc2FsZGFuYUB1bml6YXIuZXM8bWFpbHRvOmpzYWxkYW5hQHVuaXphci5lcz4+ DQpPcmdhbml6YXRpb246IFVuaXZlcnNpZGFkIGRlIFphcmFnb3phDQpSZXBseS1UbzogImpzYWxk YW5hQHVuaXphci5lczxtYWlsdG86anNhbGRhbmFAdW5pemFyLmVzPiIgPGpzYWxkYW5hQHVuaXph ci5lczxtYWlsdG86anNhbGRhbmFAdW5pemFyLmVzPj4NCkRhdGU6IGp1ZXZlcyAyMCBkZSBzZXB0 aWVtYnJlIGRlIDIwMTIgMTg6MjANClRvOiBGZXJuYW5kbyBQYXNjdWFsIEJsYW5jbyA8ZnBiQHRp ZC5lczxtYWlsdG86ZnBiQHRpZC5lcz4+LCAiZ29ycnlAZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdv cnJ5QGVyZy5hYmRuLmFjLnVrPiIgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPG1haWx0bzpnb3JyeUBl cmcuYWJkbi5hYy51az4+LCAidGNtdGZAaWV0Zi5vcmc8bWFpbHRvOnRjbXRmQGlldGYub3JnPiIg PHRjbXRmQGlldGYub3JnPG1haWx0bzp0Y210ZkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3Rj bXRmXSBEaXNjdXNzaW5nIE0yTSBzY2VuYXJpbyBhbmQgc2F2aW5ncyAtIGNvbnRpbnVpbmcgdGhl IHRocmVhZA0KDQoNClNvLCBkbyB5b3UgdGhpbmsgdGhlIGZpZ3VyZSBzaG91bGQgYmUgbW9kaWZp ZWQ/IFBlcmhhcHMgaXQgaXMgY3VycmVudGx5IGNvbmZ1c2luZywgc2luY2UgaXQgc2VlbXMgdGhh dCBSRkMgNTE2MyBpcyB0aGUgYmVzdCBzb2x1dGlvbi4gUGVyaGFwcyBhIG5ldHdvcmsgc2hvdWxk IGJlIGluY2x1ZGVkIGJldHdlZW4gdGhlIGRlbXV4IGFuZCB0aGUgZGF0YSBjZW50ZXI/IE9yIGJl dHdlZW4gdGhlIGFudGVubmEgYW5kIHRoZSBkZW11eD8gV2lsbCB0aGlzIGJlIGEgcmVhbCBjYXNl PyBJIGRvbid0IGtub3cgaWYgaW4gdGhlIHJpZ2h0IHNpZGUgaXQgaXMgcG9zc2libGUgdG8gZmlu ZCBvdGhlciBuZXR3b3Jrcy4NCg0KDQoNCkkgYW0gdGFsa2luZyBhYm91dCB0aGlzIGZpZ3VyZToN Cg0KaHR0cDovL2RpZWMudW5pemFyLmVzL35qc2FsZGFuYS9wZXJzb25hbC90Y210Zl9maWd1cmVz L20ybV9zY2VuYXJpby5wZGYNCg0KDQoNClRoYW5rcywNCg0KDQoNCkpvc2UNCg0KDQoNCi0tLS0t TWVuc2FqZSBvcmlnaW5hbC0tLS0tDQpEZTogdGNtdGYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 dGNtdGYtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzp0Y210Zi1ib3VuY2VzQGlldGYub3JnXSBF biBub21icmUgZGUgRkVSTkFORE8gUEFTQ1VBTCBCTEFOQ08NCkVudmlhZG8gZWw6IG1pw6lyY29s ZXMsIDE5IGRlIHNlcHRpZW1icmUgZGUgMjAxMiAxMzowMg0KUGFyYTogZ29ycnlAZXJnLmFiZG4u YWMudWs8bWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrPjsgdGNtdGZAaWV0Zi5vcmc8bWFpbHRv OnRjbXRmQGlldGYub3JnPg0KQXN1bnRvOiBSZTogW3RjbXRmXSBEaXNjdXNzaW5nIE0yTSBzY2Vu YXJpbyBhbmQgc2F2aW5ncyAtIGNvbnRpbnVpbmcgdGhlIHRocmVhZA0KDQoNCg0KSGkgR29ycnks DQoNCg0KDQogICAgICAgIEFic29sdXRlbHkuIFRoZSB0dW5uZWxpbmcgbGF5ZXIgd291bGQgaW5j cmVhc2UgdGhhdCBiZW5lZml0IGluIGEgbXVsdGktcm91dGVyIGhvcCBwYXRoLCBiZWluZyB0aGUg c2F0ZWxsaXRlLWxpbmsgcGFydCBvZiB0aGlzIHBhdGguDQoNCg0KDQpSZWdhcmRzLA0KDQoNCg0K RmVybmFuZG8gUGFzY3VhbCBCbGFuY28NCg0KVGVsZWbDs25pY2EgR2xvYmFsIFJlc291cmNlcw0K DQpOZXR3b3JrIEF1dG9tYXRpb24gYW5kIER5bmFtaXphdGlvbg0KDQpURUNITk9MT0dZIFBFT1BM RSBHUk9VUA0KDQpGICszNDkxMzEyODc3OQ0KDQpNICszNDY4MjAwNTE2OA0KDQpmcGJAdGlkLmVz PG1haWx0bzpmcGJAdGlkLmVzPg0KDQoNCg0KDQoNCg0KDQoNCg0KT24gMTkvMDkvMTIgMTI6Mzcs ICJnb3JyeUBlcmcuYWJkbi5hYy51azxtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWs+IiA8Z29y cnlAZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrPj4gd3JvdGU6DQoN Cg0KDQo+DQoNCj5Gb3IgYSBwb2ludC10by1wb2ludCBsaW5rIGNhcnJ5aW5nIHRyYWZmaWMgZGVz dGluZWQgdG8gYSBpbmdsZSBMMg0KDQo+YWRkcmVzcywgSSBkb24ndCBzZWUgaG93IHRoaXMgaGVs cHMgYWJvdmUgdGhlIGdhaW5zIG9mIFJPSEMgb3Igc29tZQ0KDQo+b3RoZXIgSEMgb24gdGhlIGxp bmssIHdoZW4gcG9zc2libHkgY29tYmluaW5nIHRoaXMgd2l0aCBsaW5rIGxheWVyDQoNCj50cmFu c21pc3Npb24gb3B0aW9ucyBlLmcuIG1ldGhvZHMgbGlrZSBQRFUtQ09OQ0FUIGluIFJGQyA1MTYz Lg0KDQo+DQoNCj5JZiB5b3UncmUgd29ya2luZyBvdmVyIGEgbXVsdGktcm91dGVyIG5ldHdvcmsg aG9wLCB0aGUgY29uc2lkZXJhdGlvbnMNCg0KPm1heSBiZSBkaWZmZXJlbnQuDQoNCj4NCg0KPkdv cnJ5DQoNCj4NCg0KPj4gSGkgR29ycnksDQoNCj4+DQoNCj4+ICAgICAgICAgSSBkb27DgsK0dCBr bm93IGEgbG90IGFib3V0IGxpbmsgbGF5ZXIgSEMsIGJ1dCBJIGltYWdpbmUgdGhhdA0KDQo+PiBp dCBjb21wcmVzcyBwYWNrZXQgaGVhZGVycyAoSVAtVENQL1VEUCkuIElmLCBpbiBhZGRpdGlvbiB0 byB0aGF0LCB3ZQ0KDQo+PiBncm91cCBzZXZlcmFsIHNtYWxsIHBhY2tldHMgaW50byBhIGJpZ2dl ciBvbmUgKHVzaW5nIFBQUC1NdXggYW5kDQoNCj4+IFJvSEMpLCBkb27DgsK0dCB5b3UgdGhpbmsg bW9yZSByZXNvdXJjZXMgY291bGQgYmUgc2F2ZWQ/DQoNCj4+DQoNCj4+IFJlZ2FyZHMsDQoNCj4+ DQoNCj4+IEZlcm5hbmRvIFBhc2N1YWwgQmxhbmNvDQoNCj4+IFRlbGVmw4PCs25pY2EgR2xvYmFs IFJlc291cmNlcw0KDQo+PiBOZXR3b3JrIEF1dG9tYXRpb24gYW5kIER5bmFtaXphdGlvbg0KDQo+ PiBURUNITk9MT0dZIFBFT1BMRSBHUk9VUA0KDQo+PiBGICszNDkxMzEyODc3OQ0KDQo+PiBNICsz NDY4MjAwNTE2OA0KDQo+PiBmcGJAdGlkLmVzPG1haWx0bzpmcGJAdGlkLmVzPg0KDQo+Pg0KDQo+ Pg0KDQo+Pg0KDQo+Pg0KDQo+PiBPbiAxOS8wOS8xMiAxMDo1NiwgImdvcnJ5QGVyZy5hYmRuLmFj LnVrPG1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51az4iIDxnb3JyeUBlcmcuYWJkbi5hYy51azxt YWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWs+PiB3cm90ZToNCg0KPj4NCg0KPj4+SSBrbm93IHRo ZXJlIGFyZSBhcHBsaWNhdGlvbnMgZm9yIHR1bm5lbCBjb21wcmVzc2lvbiAtIGJ1dCBJJ20gbm90 DQoNCj4+PnN1cmUgIEkgdW5kZXJzdGFuZCBob3cgdGhpcyBjYW4gZ2FpbiBmdXJ0aGVyIHRoYW4g Zm9yIGxpbmstbGF5ZXIgSEM/DQoNCj4+Pg0KDQo+Pj5Hb3JyeQ0KDQo+Pj4NCg0KPj4+PiBIaSBH b3JyeSwNCg0KPj4+Pg0KDQo+Pj4+ICAgICAgICAgSW4gYWRkaXRpb24gb2YgSEMgKGhlYWRlciBj b21wcmVzc2lvbiksIHRoZSBtdWx0aXBsZXhpbmcNCg0KPj4+PiBsYXllciB3aWxsIHNhdmUgZXZl biBtb3JlIHJlc291cmNlcy4gSW4gdGhhdCBjYXNlIGFuZCBhc3N1bWluZyB0aGF0DQoNCj4+Pj4g YWxsIHRoZSB0cmFmZmljIHRocm91Z2ggdGhlIGxpbmsgaGF2ZSB0aGUgc2FtZSBRb1MgcmVxdWly ZW1lbnRzDQoNCj4+Pj4gKGZvciBleGFtcGxlIGEgc2Vuc29yIG5ldHdvcmspLCB0aGUgaWRlYSB3 b3VsZCBiZSB0byBncm91cCBhbGwgdGhlDQoNCj4+Pj4gZmxvd3MgdGhyb3VnaCB0aGUgbGluayAo dGhlIGJvdHRsZW5lY2spLg0KDQo+Pj4+DQoNCj4+Pj4gUmVnYXJkcywNCg0KPj4+Pg0KDQo+Pj4+ IEZlcm5hbmRvIFBhc2N1YWwgQmxhbmNvDQoNCj4+Pj4gVGVsZWbDg8KzbmljYSBHbG9iYWwgUmVz b3VyY2VzDQoNCj4+Pj4gTmV0d29yayBBdXRvbWF0aW9uIGFuZCBEeW5hbWl6YXRpb24gVEVDSE5P TE9HWSBQRU9QTEUgR1JPVVAgRg0KDQo+Pj4+ICszNDkxMzEyODc3OSBNICszNDY4MjAwNTE2OCBm cGJAdGlkLmVzPG1haWx0bzpmcGJAdGlkLmVzPg0KDQo+Pj4+DQoNCj4+Pj4NCg0KPj4+Pg0KDQo+ Pj4+DQoNCj4+Pj4gT24gMTgvMDkvMTIgMjA6NDYsICJHb3JyeSBGYWlyaHVyc3QiIDxnb3JyeUBl cmcuYWJkbi5hYy51azxtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWs+PiB3cm90ZToNCg0KPj4+ Pg0KDQo+Pj4+PkEgc2F0ZWxsaXRlICJsaW5rIiBtYXkgcHJvdmlkZSBIQywgYXQgbGVhc3Qgc29t ZSBvZiB0aGUgb25lcyBJIGhhdmUNCg0KPj4+Pj5zZWVuIGRvLiBJbiB0aGlzIGNhc2UsIHRoZSBm bG93cyBjYW4gZWFzaWx5IGJlIGdyb3VwZWQgYnkgbWFjDQoNCj4+Pj4+YWRkcmVzcz8NCg0KPj4+ Pj4NCg0KPj4+Pj5Hb3JyeQ0KDQo+Pj4+Pg0KDQo+Pj4+Pk9uIDEzLzA5LzIwMTIgMTY6MjAsIEpv c2UgU2FsZGFuYSB3cm90ZToNCg0KPj4+Pj4+IEhpLCBGZXJuYW5kbywgc29ycnkgZm9yIHRoZSBk ZWxheSAob25lIHdlZWssIEnDgsK5bSBhZnJhaWQpLg0KDQo+Pj4+Pj4NCg0KPj4+Pj4+IEkgZG9u w4LCuXQga25vdyB3aG8gaXMgdGhlIG9uZSBpbnRlcmVzdGVkIG9uIHVzaW5nIFRDTVRGOg0KDQo+ Pj4+Pj4NCg0KPj4+Pj4+IC1JZiB5b3UgYXJlIGEgY29zdHVtZXIsIGFuZCB5b3UgaGF2ZSB0byBw YXkgZm9yIGEgc2F0ZWxsaXRlIGxpbmsNCg0KPj4+Pj4+b3IgIGEgIGxvbmcgZGlzdGFuY2Ugd2ly ZSwgcGVyaGFwcyB5b3UgYXJlIHRoZSBvbmUgaW50ZXJlc3RlZCBvbg0KDQo+Pj4+Pj51c2luZyAg ZW5kLXRvLWVuZCBUQ01URiwgc2luY2UgeW91IHdpbGwgc2F2ZSBiYW5kd2lkdGggb3IgcGFja2V0 cw0KDQo+Pj4+Pj5wZXIgIHNlY29uZCAgb3IgIG1vbmV5LiBJZiB5b3UgaGF2ZSBlLmcuIHR3byBv ZmZpY2VzLCBvbmUgaW4NCg0KPj4+Pj4+QW1lcmljYSBhbmQgb3RoZXIgb25lIGluICBFdXJvcGUs IHlvdSBtYXkgYmUgaW50ZXJlc3RlZCBvbiBwbGFjaW5nDQoNCj4+Pj4+PmEgZGV2aWNlIGZvciBt dWx0aXBsZXhpbmcgYSAgbnVtYmVyIG9mIFZvSVAgY2FsbHMgYmV0d2VlbiB0aGVtLg0KDQo+Pj4+ Pj5Zb3UgaGF2ZSBvbmUgYWR2YW50YWdlOiB0aGUgZmxvd3MgIGhhdmUgdGhlIHNhbWUgb3JpZ2lu IGFuZA0KDQo+Pj4+Pj5kZXN0aW5hdGlvbiwgc28gaGVhZGVyIGNvbXByZXNzaW9uIGlzIGVmZmVj dGl2ZS4NCg0KPj4+Pj4+DQoNCj4+Pj4+PiAtSWYgeW91IGFyZSB0aGUgb3BlcmF0b3Igb2YgdGhl IHNhdGVsbGl0ZSwgeW91IGhhdmUgYW5vdGhlciBwcm9ibGVtOg0KDQo+Pj4+Pj4geW91DQoNCj4+ Pj4+PiBtYXkgaGF2ZSB0byBjaGVjayBldmVyeSBmbG93LCBhbmQgdHJ5IHRvIGdyb3VwIHRoZW0u IFBlcmhhcHMgaXQNCg0KPj4+Pj4+IG1heSBiZSBlYXN5LCBidXQgaWYgeW91IHdhbnQgdG8gc2F2 ZSBoZWFkZXJzLCB5b3UgbmVlZCBmbG93cyB3aXRoDQoNCj4+Pj4+PiB0aGUgc2FtZSBvcmlnaW4g YW5kIGRlc3RpbmF0aW9uLg0KDQo+Pj4+Pj4NCg0KPj4+Pj4+IEkgdGhpbmsgdGhhdCB0aGVyZSBh cmUgZGlmZmVyZW50IHNjZW5hcmlvcywgYW5kIGVhY2ggw4LCs2FjdG9yw4LCsg0KDQo+Pj4+Pj5t YXkgIHRyeSB0byAgdXNlIFRDTVRGIGluIHRoZSBiZXN0IHBsYWNlOiBhIGhpZ2ggbnVtYmVyIG9m IGZsb3dzLA0KDQo+Pj4+Pj53aXRoIHNtYWxsICBwYWNrZXRzLCAgYW5kIHNoYXJpbmcgdGhlIHNh bWUgb3JpZ2luIGFuZCBkZXN0aW5hdGlvbi4NCg0KPj4+Pj4+DQoNCj4+Pj4+PiBEbyB5b3UgYWdy ZWU/DQoNCj4+Pj4+Pg0KDQo+Pj4+Pj4gSm9zZQ0KDQo+Pj4+Pj4NCg0KPj4+Pj4+ICpEZToqdGNt dGYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86KnRjbXRmLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWls dG86dGNtdGYtYm91bmNlc0BpZXRmLm9yZ108bWFpbHRvOlttYWlsdG86dGNtdGYtYm91bmNlc0Bp ZXRmLm9yZ10+ICpFbg0KDQo+Pj4+Pj4gbm9tYnJlIGRlICpGRVJOQU5ETyBQQVNDVUFMIEJMQU5D TyAqRW52aWFkbyBlbDoqIG1hcnRlcywgMDQgZGUNCg0KPj4+Pj4+IHNlcHRpZW1icmUgZGUgMjAx MiAxMjoyNw0KDQo+Pj4+Pj4gKlBhcmE6KiB0Y210ZkBpZXRmLm9yZzxtYWlsdG86dGNtdGZAaWV0 Zi5vcmc+DQoNCj4+Pj4+PiAqQXN1bnRvOiogUmU6IFt0Y210Zl0gRGlzY3Vzc2luZyBNMk0gc2Nl bmFyaW8gYW5kIHNhdmluZ3MNCg0KPj4+Pj4+DQoNCj4+Pj4+PiBIaSBhbGwsDQoNCj4+Pj4+Pg0K DQo+Pj4+Pj4gWWVzLCBNMk0gc2Vuc29yIG5ldHdvcmtzIGFyZSBhIHZlcnkgZ29vZCBleGFtcGxl IGluIG9yZGVyIHRvIHNhdmUNCg0KPj4+Pj4+IGJhbmR3aWR0aCBpbiBsb25nIGRpc3RhbmNlL2Jp ZyBsYXRlbmN5L2xvdyBiYW5kd2lkdGggbGlua3MsIGxpbmtzDQoNCj4+Pj4+PiB3ZXJlIHRoZSBj b3N0IHBlciBiaXQgaXMgaGlnaC4gRG8geW91IHRoaW5rIG5ldHdvcmsgY2FycmllcnMNCg0KPj4+ Pj4+IG9wZXJhdGluZyB0aGlzIGtpbmQgb2YgbGlua3MgKHNhdGVsbGl0ZSBsaW5rcyBvciBsb25n IGRpc3RhbmNlDQoNCj4+Pj4+PiB3aXJlcykgd291bGQgYmUgaW50ZXJlc3RlZCBpbiBhcHBseSBU Q01URj8NCg0KPj4+Pj4+DQoNCj4+Pj4+PiBSZWdhcmRzLA0KDQo+Pj4+Pj4NCg0KPj4+Pj4+IEZl cm5hbmRvDQoNCj4+Pj4+Pg0KDQo+Pj4+Pj4gKkZyb206KnRjbXRmLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOip0Y210Zi1ib3VuY2VzQGlldGYub3JnPiA8bWFpbHRvOnRjbXRmLWJvdW5jZXNAaWV0 Zi5vcmc+DQoNCj4+Pj4+PiBbbWFpbHRvOnRjbXRmLWJvdW5jZXNAaWV0Zi5vcmddPG1haWx0bzpb bWFpbHRvOnRjbXRmLWJvdW5jZXNAaWV0Zi5vcmddPg0KDQo+Pj4+Pj4gPG1haWx0bzpbbWFpbHRv OnRjbXRmLWJvdW5jZXNAaWV0Zi5vcmddPg0KDQo+Pj4+Pj4gKk9uIEJlaGFsZiBPZiAqSm9zZSBT YWxkYW5hDQoNCj4+Pj4+PiAqU2VudDoqIG1hcnRlcywgMDQgZGUgc2VwdGllbWJyZSBkZSAyMDEy IDk6NDENCg0KPj4+Pj4+ICpUbzoqIHRjbXRmQGlldGYub3JnPG1haWx0bzp0Y210ZkBpZXRmLm9y Zz4gPG1haWx0bzp0Y210ZkBpZXRmLm9yZz4NCg0KPj4+Pj4+ICpDYzoqIE1hdHRlby5CZXJpb2xp QGRsci5kZTxtYWlsdG86TWF0dGVvLkJlcmlvbGlAZGxyLmRlPiA8bWFpbHRvOk1hdHRlby5CZXJp b2xpQGRsci5kZT47DQoNCj4+Pj4+PiBUb21hc28uZGVDb2xhQGRsci5kZTxtYWlsdG86VG9tYXNv LmRlQ29sYUBkbHIuZGU+IDxtYWlsdG86VG9tYXNvLmRlQ29sYUBkbHIuZGU+DQoNCj4+Pj4+PiAq U3ViamVjdDoqIFt0Y210Zl0gRGlzY3Vzc2luZyBNMk0gc2NlbmFyaW8gYW5kIHNhdmluZ3MNCg0K Pj4+Pj4+DQoNCj4+Pj4+PiBIaSBhZ2FpbiwNCg0KPj4+Pj4+DQoNCj4+Pj4+PiBXZSBhbHJlYWR5 IGRpc2N1c3NlZCBzb21lIHBvaW50cyBhYm91dCB0aGUgTTJNIHNjZW5hcmlvIGF0IHRoZQ0KDQo+ Pj4+Pj5iZWdpbm5pbmcgIG9mIEF1Z3VzdC4gV2UgYXJlIGN1cnJlbnRseSBzdHVkeWluZyB0aGlz LCBhbmQgd2UgaGF2ZQ0KDQo+Pj4+Pj5idWlsdCBzb21lICBmaWd1cmVzLCBpbiBjb2xsYWJvcmF0 aW9uIHdpdGggcGVvcGxlIGZyb20gRExSIChUb21hc28NCg0KPj4+Pj4+YW5kIE1hdHRlbykuDQoN Cj4+Pj4+PllvdQ0KDQo+Pj4+Pj4gY2FuIGZpbmQgdGhlIGZpZ3VyZXMgaGVyZToNCg0KPj4+Pj4+ DQoNCj4+Pj4+Pg0KDQo+Pj4+Pj5odHRwOi8vZGllYy51bml6YXIuZXMvfmpzYWxkYW5hL3BlcnNv bmFsL3RjbXRmX2ZpZ3VyZXMvbTJtX3NhdmluZ3MNCg0KPj4+Pj4+LnBkDQoNCj4+Pj4+PmYNCg0K Pj4+Pj4+DQoNCj4+Pj4+Pg0KDQo+Pj4+Pj5odHRwOi8vZGllYy51bml6YXIuZXMvfmpzYWxkYW5h L3BlcnNvbmFsL3RjbXRmX2ZpZ3VyZXMvbTJtX3NjZW5hcmkNCg0KPj4+Pj4+by5wDQoNCj4+Pj4+ PmRmDQoNCj4+Pj4+Pg0KDQo+Pj4+Pj4gUGVyaGFwcyB3ZSBjb3VsZCBjb21tZW50IHRoZW0sIGlu IG9yZGVyIHRvIGRpc2N1c3MgdGhpcyBzY2VuYXJpbywNCg0KPj4+Pj4+IGFuZCB3ZSBtYXkgZmlu ZCBuZXcgb25lcyBpbiB3aGljaCBUQ01URiBjYW4gYmUgdXNlZnVsLg0KDQo+Pj4+Pj4NCg0KPj4+ Pj4+IFRoYW5rcywNCg0KPj4+Pj4+DQoNCj4+Pj4+PiBKb3NlDQoNCj4+Pj4+Pg0KDQo+Pj4+Pj4N Cg0KPj4+Pj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCj4+Pj4+Pi0tLQ0KDQo+Pj4+Pj4tLQ0KDQo+Pj4+Pj4tDQoN Cj4+Pj4+Pg0KDQo+Pj4+Pj4NCg0KPj4+Pj4+IEVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVz aXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlDQoNCj4+Pj4+PiBjb25zdWx0YXIgbnVl c3RyYSBwb2zDg8KtdGljYSBkZSBlbnbDg8KtbyB5IHJlY2VwY2nDg8KzbiBkZSBjb3JyZW8NCg0K Pj4+Pj4+IGVsZWN0csODwrNuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3Dg8KhcyBhYmFqby4N Cg0KPj4+Pj4+IFRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFk ZHJlc3NlZS4gV2Ugb25seQ0KDQo+Pj4+Pj4gc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUg YmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQ6DQoNCj4+Pj4+PiBodHRwOi8vd3d3LnRpZC5l cy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0KDQo+Pj4+Pj4NCg0KPj4+Pj4+DQoNCj4+Pj4+ Pg0KDQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCg0KPj4+Pj4+IHRjbXRmIG1haWxpbmcgbGlzdA0KDQo+Pj4+Pj4gdGNtdGZAaWV0Zi5vcmc8 bWFpbHRvOnRjbXRmQGlldGYub3JnPg0KDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90Y210Zg0KDQo+Pj4+Pj4NCg0KPj4+Pj4NCg0KPj4+Pj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+Pj4+PnRjbXRmIG1haWxp bmcgbGlzdA0KDQo+Pj4+PnRjbXRmQGlldGYub3JnPG1haWx0bzp0Y210ZkBpZXRmLm9yZz4NCg0K Pj4+Pj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjbXRmDQoNCj4+Pj4N Cg0KPj4+Pg0KDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4+Pj4N Cg0KPj4+PiBFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGlu YXRhcmlvLiBQdWVkZQ0KDQo+Pj4+IGNvbnN1bHRhciBudWVzdHJhIHBvbMODwq10aWNhIGRlIGVu dsODwq1vIHkgcmVjZXBjacODwrNuIGRlIGNvcnJlbw0KDQo+Pj4+IGVsZWN0csODwrNuaWNvIGVu IGVsIGVubGFjZSBzaXR1YWRvIG3Dg8KhcyBhYmFqby4NCg0KPj4+PiBUaGlzIG1lc3NhZ2UgaXMg aW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkNCg0KPj4+PiBz ZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBh dDoNCg0KPj4+PiBodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K DQo+Pj4+DQoNCj4+Pg0KDQo+Pj4NCg0KPj4NCg0KPj4NCg0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KPj4NCg0KPj4gRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNp dmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUNCg0KPj4gY29uc3VsdGFyIG51ZXN0cmEg cG9sw4PCrXRpY2EgZGUgZW52w4PCrW8geSByZWNlcGNpw4PCs24gZGUgY29ycmVvDQoNCj4+IGVs ZWN0csODwrNuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3Dg8KhcyBhYmFqby4NCg0KPj4gVGhp cyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBv bmx5IHNlbmQNCg0KPj4gYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJt cyBzZXQgb3V0IGF0Og0KDQo+PiBodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWlt ZXIuYXNweA0KDQo+Pg0KDQo+DQoNCj4NCg0KPg0KDQo+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg0KPnRjbXRmIG1haWxpbmcgbGlzdA0KDQo+dGNtdGZA aWV0Zi5vcmc8bWFpbHRvOnRjbXRmQGlldGYub3JnPg0KDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90Y210Zg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCg0KDQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEg c3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52 w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1 YWRvIG3DoXMgYWJham8uDQoNClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBm b3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBi YXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdDoNCg0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFH SU5BUy9kaXNjbGFpbWVyLmFzcHgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KdGNtdGYgbWFpbGluZyBsaXN0DQoNCnRjbXRmQGlldGYub3JnPG1h aWx0bzp0Y210ZkBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90Y210Zg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1l bnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBj b25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3Jy ZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1l c3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkg c2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQg YXQ6DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K --Boundary_(ID_xWWPZSvqhesRFS4EfIR3zA) Content-id: <37BAFFCEAD4CA342847328E2F49E721F@hi.inet> Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6YnJlYWstd29yZDsgY29sb3I6cmdiKDAsMCwwKTsgZm9udC1zaXplOjE0cHg7IGZvbnQtZmFt aWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+SGkgSm9zZSw8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIg c3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPkkgdGhpbmsgdGhlcmUgd2lsbCBiZSBzZXZl cmFsIGxheWVyIDMgaG9wcyBiZXR3ZWVuIHRoZSBkZW11eCBhbmQgdGhlIGRhdGEgY2VudGVyIGFu ZCBub3QgaW4gdGhlIG90aGVyIHNpZGUuJm5ic3A7PC9kaXY+DQo8ZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+UmVnYXJkcyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkZlcm5h bmRvIFBhc2N1YWwgQmxhbmNvPC9kaXY+DQo8ZGl2PlRlbGVmw7NuaWNhIEdsb2JhbCBSZXNvdXJj ZXM8L2Rpdj4NCjxkaXY+TmV0d29yayBBdXRvbWF0aW9uIGFuZCBEeW5hbWl6YXRpb248L2Rpdj4N CjxkaXY+VEVDSE5PTE9HWSBQRU9QTEUgR1JPVVA8L2Rpdj4NCjxkaXY+RiAmIzQzOzM0OTEzMTI4 Nzc5PC9kaXY+DQo8ZGl2Pk0gJiM0MzszNDY4MjAwNTE2ODwvZGl2Pg0KPGRpdj5mcGJAdGlkLmVz PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4g aWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBib3JkZXIt Ym90dG9tOm1lZGl1bSBub25lOyBib3JkZXItbGVmdDptZWRpdW0gbm9uZTsgcGFkZGluZy1ib3R0 b206MGluOyBwYWRkaW5nLWxlZnQ6MGluOyBwYWRkaW5nLXJpZ2h0OjBpbjsgYm9yZGVyLXRvcDoj YjVjNGRmIDFwdCBzb2xpZDsgYm9yZGVyLXJpZ2h0Om1lZGl1bSBub25lOyBwYWRkaW5nLXRvcDoz cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDs8 YSBocmVmPSJtYWlsdG86anNhbGRhbmFAdW5pemFyLmVzIj5qc2FsZGFuYUB1bml6YXIuZXM8L2E+ JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86anNhbGRhbmFAdW5pemFyLmVzIj5qc2FsZGFuYUB1 bml6YXIuZXM8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Pcmdh bml6YXRpb246IDwvc3Bhbj5Vbml2ZXJzaWRhZCBkZSBaYXJhZ296YTxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5SZXBseS1UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0 bzpqc2FsZGFuYUB1bml6YXIuZXMiPmpzYWxkYW5hQHVuaXphci5lczwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpqc2FsZGFuYUB1bml6YXIuZXMiPmpzYWxkYW5hQHVuaXphci5lczwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5qdWV2 ZXMgMjAgZGUgc2VwdGllbWJyZSBkZSAyMDEyIDE4OjIwPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+RmVybmFuZG8gUGFzY3VhbCBCbGFuY28gJmx0OzxhIGhy ZWY9Im1haWx0bzpmcGJAdGlkLmVzIj5mcGJAdGlkLmVzPC9hPiZndDssICZxdW90OzxhIGhyZWY9 Im1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51ayI+Z29ycnlAZXJnLmFiZG4uYWMudWs8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWsiPmdvcnJ5QGVyZy5h YmRuLmFjLnVrPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzp0Y210ZkBpZXRmLm9yZyI+ dGNtdGZAaWV0Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzp0Y210ZkBpZXRm Lm9yZyI+dGNtdGZAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFt0Y210Zl0gRGlzY3Vzc2luZyBNMk0gc2NlbmFy aW8gYW5kIHNhdmluZ3MgLSBjb250aW51aW5nIHRoZSB0aHJlYWQ8YnI+DQo8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PjxzdHlsZT4NCjwhLS0NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCJ9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicml9DQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIn0NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7Y29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lfQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lfQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4 dA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiJ9DQpzcGFuLlRleHRvc2lu Zm9ybWF0b0Nhcg0KCXtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYifQ0KLk1zb0No cERlZmF1bHQNCgl7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIn0NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXttYXJnaW46NzAuODVwdCAzLjBjbSA3MC44NXB0IDMuMGNtfQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXt9DQotLT4NCjwvc3R5bGU+DQo8ZGl2IGxhbmc9IkVTIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+U28sIGRvIHlvdSB0aGluayB0aGUgZmlndXJlIHNob3VsZCBiZSBtb2RpZmllZD8gUGVy aGFwcyBpdCBpcyBjdXJyZW50bHkgY29uZnVzaW5nLCBzaW5jZSBpdCBzZWVtcyB0aGF0IFJGQyA1 MTYzIGlzIHRoZSBiZXN0IHNvbHV0aW9uLiBQZXJoYXBzIGEgbmV0d29yayBzaG91bGQgYmUgaW5j bHVkZWQgYmV0d2VlbiB0aGUgZGVtdXggYW5kIHRoZSBkYXRhIGNlbnRlcj8gT3IgYmV0d2Vlbg0K IHRoZSBhbnRlbm5hIGFuZCB0aGUgZGVtdXg/IFdpbGwgdGhpcyBiZSBhIHJlYWwgY2FzZT8gSSBk b24ndCBrbm93IGlmIGluIHRoZSByaWdodCBzaWRlIGl0IGlzIHBvc3NpYmxlIHRvIGZpbmQgb3Ro ZXIgbmV0d29ya3MuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPkkgYW0gdGFsa2luZyBhYm91dCB0aGlzIGZpZ3VyZTo8L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0 dHA6Ly9kaWVjLnVuaXphci5lcy9+anNhbGRhbmEvcGVyc29uYWwvdGNtdGZfZmlndXJlcy9tMm1f c2NlbmFyaW8ucGRmIj5odHRwOi8vZGllYy51bml6YXIuZXMvfmpzYWxkYW5hL3BlcnNvbmFsL3Rj bXRmX2ZpZ3VyZXMvbTJtX3NjZW5hcmlvLnBkZjwvYT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzLDwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5Kb3NlPC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSIiPi0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tPGJyPg0KRGU6IDxhIGhyZWY9Im1haWx0 bzp0Y210Zi1ib3VuY2VzQGlldGYub3JnIj50Y210Zi1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEg aHJlZj0ibWFpbHRvOnRjbXRmLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzp0Y210Zi1ib3VuY2Vz QGlldGYub3JnPC9hPl0gRW4gbm9tYjwvc3Bhbj48c3BhbiBzdHlsZT0iIj5yZSBkZSBGRVJOQU5E TyBQQVNDVUFMIEJMQU5DTzxicj4NCkVudmlhZG8gZWw6IG1pw6lyY29sZXMsIDE5IGRlIHNlcHRp ZW1icmUgZGUgMjAxMiAxMzowMjxicj4NClBhcmE6IDxhIGhyZWY9Im1haWx0bzpnb3JyeUBlcmcu YWJkbi5hYy51ayI+Z29ycnlAZXJnLmFiZG4uYWMudWs8L2E+OyA8YSBocmVmPSJtYWlsdG86dGNt dGZAaWV0Zi5vcmciPg0KdGNtdGZAaWV0Zi5vcmc8L2E+PGJyPg0KQXN1bnRvOiBSZTogW3RjbXRm XSBEaXNjdXNzaW5nIE0yTSBzY2VuYXJpbyBhbmQgc2F2aW5ncyAtIGNvbnRpbnVpbmcgdGhlIHRo cmVhZDwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5IaSBHb3JyeSw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQWJzb2x1dGVseS4gVGhlIHR1bm5lbGluZyBsYXllciB3 b3VsZCBpbmNyZWFzZSB0aGF0IGJlbmVmaXQgaW4gYSBtdWx0aS1yb3V0ZXIgaG9wIHBhdGgsIGJl aW5nIHRoZSBzYXRlbGxpdGUtbGluayBwYXJ0IG9mIHRoaXMgcGF0aC48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SZWdhcmRz LDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkZlcm5hbmRvIFBhc2N1YWwgQmxhbmNvPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+VGVsZWbDs25pY2EgR2xvYmFsIFJlc291cmNlczwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPk5ldHdvcmsgQXV0b21hdGlvbiBhbmQgRHluYW1pemF0aW9uPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+VEVDSE5PTE9HWSBQRU9QTEUgR1JPVVA8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5GICYjNDM7MzQ5MTMxMjg3Nzk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5NICYjNDM7MzQ2ODIwMDUxNjg8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVm PSJtYWlsdG86ZnBiQHRpZC5lcyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7IHRleHQt ZGVjb3JhdGlvbjpub25lIj5mcGJAdGlkLmVzPC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5PbiAxOS8wOS8xMiAxMjoz NywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDsgdGV4dC1kZWNvcmF0aW9uOm5vbmUiPmdvcnJ5QGVyZy5hYmRu LmFjLnVrPC9zcGFuPjwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpnb3JyeUBlcmcuYWJk bi5hYy51ayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7IHRleHQtZGVjb3JhdGlvbjpu b25lIj5nb3JyeUBlcmcuYWJkbi5hYy51azwvc3Bhbj48L2E+Jmd0Ow0KIHdyb3RlOjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Rm9yIGEgcG9pbnQt dG8tcG9pbnQgbGluayBjYXJyeWluZyB0cmFmZmljIGRlc3RpbmVkIHRvIGEgaW5nbGUgTDINCjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDthZGRyZXNzLCBJIGRvbid0IHNlZSBob3cg dGhpcyBoZWxwcyBhYm92ZSB0aGUgZ2FpbnMgb2YgUk9IQyBvciBzb21lDQo8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7b3RoZXIgSEMgb24gdGhlIGxpbmssIHdoZW4gcG9zc2libHkg Y29tYmluaW5nIHRoaXMgd2l0aCBsaW5rIGxheWVyDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7dHJhbnNtaXNzaW9uIG9wdGlvbnMgZS5nLiBtZXRob2RzIGxpa2UgUERVLUNPTkNB VCBpbiBSRkMgNTE2My48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0O0lmIHlvdSdyZSB3b3JraW5nIG92ZXIgYSBt dWx0aS1yb3V0ZXIgbmV0d29yayBob3AsIHRoZSBjb25zaWRlcmF0aW9ucw0KPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0O21heSBiZSBkaWZmZXJlbnQuPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDtH b3JyeTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyBIaSBHb3JyeSw8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgZG9u w4LCtHQga25vdyBhIGxvdCBhYm91dCBsaW5rIGxheWVyIEhDLCBidXQgSSBpbWFnaW5lIHRoYXQN CjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IGl0IGNvbXByZXNzIHBhY2tl dCBoZWFkZXJzIChJUC1UQ1AvVURQKS4gSWYsIGluIGFkZGl0aW9uIHRvIHRoYXQsIHdlDQo8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyBncm91cCBzZXZlcmFsIHNtYWxsIHBh Y2tldHMgaW50byBhIGJpZ2dlciBvbmUgKHVzaW5nIFBQUC1NdXggYW5kDQo8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyBSb0hDKSwgZG9uw4LCtHQgeW91IHRoaW5rIG1vcmUg cmVzb3VyY2VzIGNvdWxkIGJlIHNhdmVkPzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsmZ3Q7Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgUmVnYXJk cyw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IEZlcm5hbmRvIFBhc2N1YWwgQmxhbmNvPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgVGVsZWbDg8KzbmljYSBHbG9iYWwgUmVz b3VyY2VzPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgTmV0d29yayBBdXRv bWF0aW9uIGFuZCBEeW5hbWl6YXRpb248L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 Jmd0OyBURUNITk9MT0dZIFBFT1BMRSBHUk9VUDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7IEYgJiM0MzszNDkxMzEyODc3OTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7IE0gJiM0MzszNDY4MjAwNTE2ODwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpmcGJAdGlkLmVzIj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dDsgdGV4dC1kZWNvcmF0aW9uOm5vbmUiPmZwYkB0aWQuZXM8L3NwYW4+PC9hPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jm5ic3A7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jm5i c3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgT24gMTkvMDkvMTIgMTA6 NTYsICZxdW90OzxhIGhyZWY9Im1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51ayI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQ7IHRleHQtZGVjb3JhdGlvbjpub25lIj5nb3JyeUBlcmcuYWJk bi5hYy51azwvc3Bhbj48L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Z29ycnlAZXJnLmFi ZG4uYWMudWsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0OyB0ZXh0LWRlY29yYXRpb246 bm9uZSI+Z29ycnlAZXJnLmFiZG4uYWMudWs8L3NwYW4+PC9hPiZndDsNCiB3cm90ZTo8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsmZ3Q7Jmd0O0kga25vdyB0aGVyZSBhcmUgYXBwbGljYXRpb25zIGZvciB0 dW5uZWwgY29tcHJlc3Npb24gLSBidXQgSSdtIG5vdA0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZndDsmZ3Q7c3VyZSZuYnNwOyBJIHVuZGVyc3RhbmQgaG93IHRoaXMgY2FuIGdh aW4gZnVydGhlciB0aGFuIGZvciBsaW5rLWxheWVyIEhDPzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsmZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsmZ3Q7Jmd0O0dvcnJ5PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7 Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyBIaSBH b3JyeSw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJbiBhZGRpdGlvbiBvZiBIQyAo aGVhZGVyIGNvbXByZXNzaW9uKSwgdGhlIG11bHRpcGxleGluZw0KPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyBsYXllciB3aWxsIHNhdmUgZXZlbiBtb3JlIHJl c291cmNlcy4gSW4gdGhhdCBjYXNlIGFuZCBhc3N1bWluZyB0aGF0DQo8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7IGFsbCB0aGUgdHJhZmZpYyB0aHJvdWdoIHRo ZSBsaW5rIGhhdmUgdGhlIHNhbWUgUW9TIHJlcXVpcmVtZW50cw0KPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyAoZm9yIGV4YW1wbGUgYSBzZW5zb3IgbmV0d29y ayksIHRoZSBpZGVhIHdvdWxkIGJlIHRvIGdyb3VwIGFsbCB0aGUNCjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgZmxvd3MgdGhyb3VnaCB0aGUgbGluayAodGhl IGJvdHRsZW5lY2spLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7IFJl Z2FyZHMsPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgRmVybmFuZG8g UGFzY3VhbCBCbGFuY288L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsm Z3Q7IFRlbGVmw4PCs25pY2EgR2xvYmFsIFJlc291cmNlczwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgTmV0d29yayBBdXRvbWF0aW9uIGFuZCBEeW5hbWl6YXRp b24gVEVDSE5PTE9HWSBQRU9QTEUgR1JPVVAgRg0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyZndDsmZ3Q7Jmd0OyAmIzQzOzM0OTEzMTI4Nzc5IE0gJiM0MzszNDY4MjAwNTE2OCA8 YSBocmVmPSJtYWlsdG86ZnBiQHRpZC5lcyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dDsgdGV4dC1kZWNvcmF0aW9uOm5vbmUiPmZwYkB0aWQuZXM8L3NwYW4+PC9hPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jmd0OyZndDsmZ3Q7IE9uIDE4LzA5LzEyIDIwOjQ2LCAmcXVvdDtHb3JyeSBGYWlyaHVyc3Qm cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51ayI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQ7IHRleHQtZGVjb3JhdGlvbjpub25lIj5nb3JyeUBlcmcuYWJk bi5hYy51azwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDtBIHNhdGVsbGl0ZSAmcXVvdDtsaW5rJnF1b3Q7IG1heSBwcm92aWRl IEhDLCBhdCBsZWFzdCBzb21lIG9mIHRoZSBvbmVzIEkgaGF2ZSZuYnNwOw0KPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDtzZWVuIGRvLiBJbiB0aGlzIGNh c2UsIHRoZSBmbG93cyBjYW4gZWFzaWx5IGJlIGdyb3VwZWQgYnkgbWFjDQo8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O2FkZHJlc3M/PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O0dvcnJ5PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O09uIDEzLzA5LzIwMTIgMTY6MjAsIEpv c2UgU2FsZGFuYSB3cm90ZTo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgSGksIEZlcm5hbmRvLCBzb3JyeSBmb3IgdGhlIGRlbGF5IChvbmUgd2Vl aywgScOCwrltIGFmcmFpZCkuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgZG9uw4LCuXQga25vdyB3aG8gaXMgdGhlIG9uZSBpbnRlcmVz dGVkIG9uIHVzaW5nIFRDTVRGOjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtSWYgeW91IGFyZSBhIGNvc3R1bWVyLCBhbmQgeW91IGhhdmUg dG8gcGF5IGZvciBhIHNhdGVsbGl0ZSBsaW5rDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDtvciZuYnNwOyBhJm5ic3A7IGxvbmcgZGlzdGFuY2Ug d2lyZSwgcGVyaGFwcyB5b3UgYXJlIHRoZSBvbmUgaW50ZXJlc3RlZCBvbg0KPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7dXNpbmcmbmJzcDsgZW5k LXRvLWVuZCBUQ01URiwgc2luY2UgeW91IHdpbGwgc2F2ZSBiYW5kd2lkdGggb3IgcGFja2V0cw0K PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7cGVy Jm5ic3A7IHNlY29uZCZuYnNwOyBvciZuYnNwOyBtb25leS4gSWYgeW91IGhhdmUgZS5nLiB0d28g b2ZmaWNlcywgb25lIGluDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDtBbWVyaWNhIGFuZCBvdGhlciBvbmUgaW4mbmJzcDsgRXVyb3BlLCB5b3Ug bWF5IGJlIGludGVyZXN0ZWQgb24gcGxhY2luZw0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7YSBkZXZpY2UgZm9yIG11bHRpcGxleGluZyBhJm5i c3A7IG51bWJlciBvZiBWb0lQIGNhbGxzIGJldHdlZW4gdGhlbS4NCjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O1lvdSBoYXZlIG9uZSBhZHZhbnRh Z2U6IHRoZSBmbG93cyZuYnNwOyBoYXZlIHRoZSBzYW1lIG9yaWdpbiBhbmQNCjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O2Rlc3RpbmF0aW9uLCBz byBoZWFkZXIgY29tcHJlc3Npb24gaXMgZWZmZWN0aXZlLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtSWYgeW91IGFyZSB0aGUgb3BlcmF0 b3Igb2YgdGhlIHNhdGVsbGl0ZSwgeW91IGhhdmUgYW5vdGhlciBwcm9ibGVtOjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB5b3U8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbWF5IGhhdmUgdG8g Y2hlY2sgZXZlcnkgZmxvdywgYW5kIHRyeSB0byBncm91cCB0aGVtLiBQZXJoYXBzIGl0DQo8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbWF5IGJl IGVhc3ksIGJ1dCBpZiB5b3Ugd2FudCB0byBzYXZlIGhlYWRlcnMsIHlvdSBuZWVkIGZsb3dzIHdp dGgNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyB0aGUgc2FtZSBvcmlnaW4gYW5kIGRlc3RpbmF0aW9uLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIHRoaW5rIHRoYXQgdGhlcmUgYXJl IGRpZmZlcmVudCBzY2VuYXJpb3MsIGFuZCBlYWNoIMOCwrNhY3RvcsOCwrINCjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O21heSZuYnNwOyB0cnkg dG8mbmJzcDsgdXNlIFRDTVRGIGluIHRoZSBiZXN0IHBsYWNlOiBhIGhpZ2ggbnVtYmVyIG9mIGZs b3dzLA0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7d2l0aCBzbWFsbCZuYnNwOyBwYWNrZXRzLCZuYnNwOyBhbmQgc2hhcmluZyB0aGUgc2FtZSBv cmlnaW4gYW5kIGRlc3RpbmF0aW9uLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBEbyB5b3UgYWdyZWU/PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEpvc2U8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKkRlOjxhIGhyZWY9Im1h aWx0bzoqdGNtdGYtYm91bmNlc0BpZXRmLm9yZyI+KnRjbXRmLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ DQo8YSBocmVmPSJtYWlsdG86W21haWx0bzp0Y210Zi1ib3VuY2VzQGlldGYub3JnXSI+PHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7IHRleHQtZGVjb3JhdGlvbjpub25lIj5bbWFpbHRvOnRj bXRmLWJvdW5jZXNAaWV0Zi5vcmddPC9zcGFuPjwvYT4gKkVuDQo8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbm9tYnJlIGRlICpGRVJOQU5ETyBQ QVNDVUFMIEJMQU5DTyAqRW52aWFkbyBlbDoqIG1hcnRlcywgMDQgZGUNCjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXB0aWVtYnJlIGRlIDIw MTIgMTI6Mjc8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgKlBhcmE6KiA8YSBocmVmPSJtYWlsdG86dGNtdGZAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0OyB0ZXh0LWRlY29yYXRpb246bm9uZSI+dGNtdGZAaWV0Zi5vcmc8 L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAqQXN1bnRvOiogUmU6IFt0Y210Zl0gRGlzY3Vzc2luZyBNMk0gc2NlbmFyaW8gYW5k IHNhdmluZ3M8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgSGkgYWxsLDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBZZXMsIE0yTSBzZW5zb3IgbmV0d29ya3MgYXJlIGEgdmVyeSBnb29k IGV4YW1wbGUgaW4gb3JkZXIgdG8gc2F2ZQ0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJhbmR3aWR0aCBpbiBsb25nIGRpc3RhbmNlL2JpZyBs YXRlbmN5L2xvdyBiYW5kd2lkdGggbGlua3MsIGxpbmtzDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2VyZSB0aGUgY29zdCBwZXIgYml0IGlz IGhpZ2guIERvIHlvdSB0aGluayBuZXR3b3JrIGNhcnJpZXJzDQo8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb3BlcmF0aW5nIHRoaXMga2luZCBv ZiBsaW5rcyAoc2F0ZWxsaXRlIGxpbmtzIG9yIGxvbmcgZGlzdGFuY2UNCjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aXJlcykgd291bGQgYmUg aW50ZXJlc3RlZCBpbiBhcHBseSBUQ01URj88L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUmVnYXJkcyw8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRmVybmFuZG88L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKkZyb206PGEgaHJl Zj0ibWFpbHRvOip0Y210Zi1ib3VuY2VzQGlldGYub3JnIj4qdGNtdGYtYm91bmNlc0BpZXRmLm9y ZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzp0Y210Zi1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dDsgdGV4dC1kZWNvcmF0aW9uOm5vbmUiPm1haWx0bzp0Y210 Zi1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7DQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86 dGNtdGYtYm91bmNlc0BpZXRmLm9yZ10iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0OyB0 ZXh0LWRlY29yYXRpb246bm9uZSI+W21haWx0bzp0Y210Zi1ib3VuY2VzQGlldGYub3JnXTwvc3Bh bj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86W21haWx0bzp0Y210Zi1ib3VuY2VzQGlldGYub3JnXSI+ PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7IHRleHQtZGVjb3JhdGlvbjpub25lIj5tYWls dG86W21haWx0bzp0Y210Zi1ib3VuY2VzQGlldGYub3JnXTwvc3Bhbj48L2E+Jmd0OzwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqT24gQmVoYWxm IE9mICpKb3NlIFNhbGRhbmE8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgKlNlbnQ6KiBtYXJ0ZXMsIDA0IGRlIHNlcHRpZW1icmUgZGUgMjAxMiA5 OjQxPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 ICpUbzoqIDxhIGhyZWY9Im1haWx0bzp0Y210ZkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7IHRleHQtZGVjb3JhdGlvbjpub25lIj50Y210ZkBpZXRmLm9yZzwvc3Bhbj48 L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86dGNtdGZAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0OyB0ZXh0LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOnRjbXRmQGlldGYub3Jn PC9zcGFuPjwvYT4mZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7ICpDYzoqIDxhIGhyZWY9Im1haWx0bzpNYXR0ZW8uQmVyaW9saUBkbHIuZGUi PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0OyB0ZXh0LWRlY29yYXRpb246bm9uZSI+TWF0 dGVvLkJlcmlvbGlAZGxyLmRlPC9zcGFuPjwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpNYXR0ZW8u QmVyaW9saUBkbHIuZGUiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0OyB0ZXh0LWRlY29y YXRpb246bm9uZSI+bWFpbHRvOk1hdHRlby5CZXJpb2xpQGRsci5kZTwvc3Bhbj48L2E+Jmd0OzsN CjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8 YSBocmVmPSJtYWlsdG86VG9tYXNvLmRlQ29sYUBkbHIuZGUiPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0OyB0ZXh0LWRlY29yYXRpb246bm9uZSI+VG9tYXNvLmRlQ29sYUBkbHIuZGU8L3Nw YW4+PC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRvbWFzby5kZUNvbGFAZGxyLmRlIj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dDsgdGV4dC1kZWNvcmF0aW9uOm5vbmUiPm1haWx0bzpUb21h c28uZGVDb2xhQGRsci5kZTwvc3Bhbj48L2E+Jmd0OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqU3ViamVjdDoqIFt0Y210Zl0gRGlzY3Vzc2lu ZyBNMk0gc2NlbmFyaW8gYW5kIHNhdmluZ3M8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSGkgYWdhaW4sPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdlIGFscmVhZHkgZGlzY3Vzc2Vk IHNvbWUgcG9pbnRzIGFib3V0IHRoZSBNMk0gc2NlbmFyaW8gYXQgdGhlJm5ic3A7DQo8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDtiZWdpbm5pbmcm bmJzcDsgb2YgQXVndXN0LiBXZSBhcmUgY3VycmVudGx5IHN0dWR5aW5nIHRoaXMsIGFuZCB3ZSBo YXZlDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDtidWlsdCBzb21lJm5ic3A7IGZpZ3VyZXMsIGluIGNvbGxhYm9yYXRpb24gd2l0aCBwZW9wbGUg ZnJvbSBETFIgKFRvbWFzbw0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7YW5kIE1hdHRlbykuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7WW91PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNhbiBmaW5kIHRoZSBmaWd1cmVzIGhlcmU6PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGEg aHJlZj0iaHR0cDovL2RpZWMudW5pemFyLmVzL35qc2FsZGFuYS9wZXJzb25hbC90Y210Zl9maWd1 cmVzL20ybV9zYXZpbmdzIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDsgdGV4dC1kZWNv cmF0aW9uOm5vbmUiPmh0dHA6Ly9kaWVjLnVuaXphci5lcy9+anNhbGRhbmEvcGVyc29uYWwvdGNt dGZfZmlndXJlcy9tMm1fc2F2aW5nczwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LnBkPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ZjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzxhIGhyZWY9Imh0dHA6Ly9kaWVjLnVu aXphci5lcy9+anNhbGRhbmEvcGVyc29uYWwvdGNtdGZfZmlndXJlcy9tMm1fc2NlbmFyaSI+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7IHRleHQtZGVjb3JhdGlvbjpub25lIj5odHRwOi8v ZGllYy51bml6YXIuZXMvfmpzYWxkYW5hL3BlcnNvbmFsL3RjbXRmX2ZpZ3VyZXMvbTJtX3NjZW5h cmk8L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0O28ucDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0O2RmPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFBlcmhhcHMgd2UgY291bGQgY29tbWVudCB0aGVtLCBpbiBvcmRlciB0byBk aXNjdXNzIHRoaXMgc2NlbmFyaW8sDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYW5kIHdlIG1heSBmaW5kIG5ldyBvbmVzIGluIHdoaWNoIFRD TVRGIGNhbiBiZSB1c2VmdWwuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcyw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSm9zZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tLTwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Oy0tPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7LTwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBFc3RlIG1lbnNhamUg c2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZQ0KPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbnN1bHRh ciBudWVzdHJhIHBvbMODwq10aWNhIGRlIGVudsODwq1vIHkgcmVjZXBjacODwrNuIGRlIGNvcnJl bw0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGVsZWN0csODwrNuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3Dg8KhcyBhYmFqby48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBtZXNz YWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5DQo8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2Vu ZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQ6 PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxh IGhyZWY9Imh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4Ij4NCjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0OyB0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDov L3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHg8L3NwYW4+PC9hPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0Y210ZiBtYWlsaW5n IGxpc3Q8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgPGEgaHJlZj0ibWFpbHRvOnRjbXRmQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dDsgdGV4dC1kZWNvcmF0aW9uOm5vbmUiPnRjbXRmQGlldGYub3JnPC9zcGFuPjwvYT48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y210ZiI+DQo8c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dDsgdGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNtdGY8L3NwYW4+PC9hPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDtfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7dGNtdGYgbWFpbGluZyBsaXN0PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YSBocmVmPSJtYWlsdG86dGNtdGZA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0OyB0ZXh0LWRlY29yYXRpb246 bm9uZSI+dGNtdGZAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90Y210ZiI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7IHRleHQt ZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rj bXRmPC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZn dDsmZ3Q7Jmd0OyBFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVz dGluYXRhcmlvLiBQdWVkZQ0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsm Z3Q7Jmd0OyBjb25zdWx0YXIgbnVlc3RyYSBwb2zDg8KtdGljYSBkZSBlbnbDg8KtbyB5IHJlY2Vw Y2nDg8KzbiBkZSBjb3JyZW8NCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 Jmd0OyZndDsgZWxlY3Ryw4PCs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcODwqFzIGFiYWpv LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBtZXNz YWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5DQo8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7IHNlbmQgYW5kIHJl Y2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0OjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL3d3 dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7IHRleHQtZGVjb3JhdGlvbjpub25lIj5odHRwOi8vd3d3LnRpZC5lcy9FUy9Q QUdJTkFTL2Rpc2NsYWltZXIuYXNweDwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jm5ic3A7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDs8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jm5ic3A7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFt ZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsmZ3Q7IGNvbnN1bHRhciBudWVzdHJhIHBvbMODwq10aWNhIGRlIGVudsODwq1vIHkg cmVjZXBjacODwrNuIGRlIGNvcnJlbw0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyZndDsgZWxlY3Ryw4PCs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcODwqFzIGFiYWpvLjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IFRoaXMgbWVzc2FnZSBpcyBpbnRl bmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kDQo8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUg YmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQ6PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFp bWVyLmFzcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7IHRleHQtZGVjb3JhdGlv bjpub25lIj5odHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweDwvc3Bh bj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDs8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDs8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 dGNtdGYgbWFpbGluZyBsaXN0PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxhIGhy ZWY9Im1haWx0bzp0Y210ZkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7 IHRleHQtZGVjb3JhdGlvbjpub25lIj50Y210ZkBpZXRmLm9yZzwvc3Bhbj48L2E+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdGNtdGYiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0OyB0ZXh0 LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 Y210Zjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Fc3RlIG1lbnNhamUg c2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0 YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxl Y3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8uPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+VGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBp dHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lz IG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0OjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxh IGhyZWY9Imh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4Ij48c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dDsgdGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHA6Ly93 d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4PC9zcGFuPjwvYT48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnRjbXRmIG1haWxpbmcgbGlz dDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9Im1haWx0bzp0Y210ZkBpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7IHRleHQtZGVjb3JhdGlvbjpub25l Ij50Y210ZkBpZXRmLm9yZzwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y210ZiI+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7IHRleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjbXRmPC9zcGFuPjwvYT48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwi IGNvbG9yPSJHcmF5IiBzaXplPSIxIj48YnI+DQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1 c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zD rXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVs IGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8uPGJyPg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVk IGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUg ZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Ojxicj4NCmh0dHA6Ly93 d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4PGJyPg0KPC9mb250Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --Boundary_(ID_xWWPZSvqhesRFS4EfIR3zA)-- From gorry@erg.abdn.ac.uk Fri Sep 21 01:29:12 2012 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 591C721F8780 for ; Fri, 21 Sep 2012 01:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHRNyzc5IglW for ; Fri, 21 Sep 2012 01:29:11 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id B425D21F877A for ; Fri, 21 Sep 2012 01:29:10 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 4F2CE2B45AF; Fri, 21 Sep 2012 09:29:09 +0100 (BST) Received: from Gorry.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 03D7F2B451D; Fri, 21 Sep 2012 09:29:05 +0100 (BST) Message-ID: <505C2550.4050107@erg.abdn.ac.uk> Date: Fri, 21 Sep 2012 09:29:04 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: jsaldana@unizar.es References: <5e16ec8fc82258693e7d0d5ed433b0e4.squirrel@www.erg.abdn.ac.uk> <005401cd974b$ddd88b70$9989a250$@unizar.es> In-Reply-To: <005401cd974b$ddd88b70$9989a250$@unizar.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: tcmtf@ietf.org, 'FERNANDO PASCUAL BLANCO' Subject: Re: [tcmtf] Discussing M2M scenario and savings - continuing the thread X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk 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 Sep 2012 08:29:12 -0000 I think *IF* the satellite link is a DVB 2nd generation RF link, e.g. DVB-S2 for satellite ( a common waveform), then GSE + RFC 5163 is a reasonable proposal, on which one may benefit if one layers a HC scheme, such as ROHC, or 6LoWPAN. The profile for the ROHC schemes have not been specified for this type of link - but the relevant RFCs exist for the compression itself. RFC 3135 and RFC 3449 also describe TCP/IP techniques to help improve efficiency on such links. As I said, I do not see the *benefit* for the mux and demux in the scenario as drawn, since this seems more like *link* HC, and it would seem foolish to form aggregate traffic over a single link layer in the way that tunnel compression implements this. If the drawing extended the network on one or both sides of the satellite link, there could be a reason for using tunnel HC, although I am not sure whether this is commercially important, since unlike an access network, the connectivity to the hub (usually known as the satellite gateway) on the left of the figure is not usually a low speed access link and the merits of HC is less obvious where bandwidth is high. Also, it would seem desirable to use encapsulation and HC mechanisms on the satellite air interface anyway, RFC 3135 part 3 (from the source), possibly combined with RFC 3449 mechanisms. All I am saying is you have to be sure to describe the scenario carefully and explain why HC applies in this case and what alternatives exist. Gorry On 20/09/2012 17:20, Jose Saldana wrote: > So, do you think the figure should be modified? Perhaps it is currently > confusing, since it seems that RFC 5163 is the best solution. Perhaps a > network should be included between the demux and the data center? Or > between the antenna and the demux? Will this be a real case? I don't > know if in the right side it is possible to find other networks. > > I am talking about this figure: > > http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenario.pdf > > Thanks, > > Jose > > -----Mensaje original----- > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de > FERNANDO PASCUAL BLANCO > Enviado el: mi�rcoles, 19 de septiembre de 2012 13:02 > Para: gorry@erg.abdn.ac.uk; tcmtf@ietf.org > Asunto: Re: [tcmtf] Discussing M2M scenario and savings - continuing the > thread > > Hi Gorry, > > Absolutely. The tunneling layer would increase that benefit in > a multi-router hop path, being the satellite-link part of this path. > > Regards, > > Fernando Pascual Blanco > > Telef�nica Global Resources > > Network Automation and Dynamization > > TECHNOLOGY PEOPLE GROUP > > F +34913128779 > > M +34682005168 > > fpb@tid.es > > On 19/09/12 12:37, "gorry@erg.abdn.ac.uk " > > wrote: > > > > > >For a point-to-point link carrying traffic destined to a ingle L2 > > >address, I don't see how this helps above the gains of ROHC or some > > >other HC on the link, when possibly combining this with link layer > > >transmission options e.g. methods like PDU-CONCAT in RFC 5163. > > > > > >If you're working over a multi-router network hop, the considerations > > >may be different. > > > > > >Gorry > > > > > >> Hi Gorry, > > >> > > >> I don´t know a lot about link layer HC, but I imagine that > > >> it compress packet headers (IP-TCP/UDP). If, in addition to that, we > > >> group several small packets into a bigger one (using PPP-Mux and > > >> RoHC), don´t you think more resources could be saved? > > >> > > >> Regards, > > >> > > >> Fernando Pascual Blanco > > >> Telefónica Global Resources > > >> Network Automation and Dynamization > > >> TECHNOLOGY PEOPLE GROUP > > >> F +34913128779 > > >> M +34682005168 > > >> fpb@tid.es > > >> > > >> > > >> > > >> > > >> On 19/09/12 10:56, "gorry@erg.abdn.ac.uk > " > wrote: > > >> > > >>>I know there are applications for tunnel compression - but I'm not > > >>>sure I understand how this can gain further than for link-layer HC? > > >>> > > >>>Gorry > > >>> > > >>>> Hi Gorry, > > >>>> > > >>>> In addition of HC (header compression), the multiplexing > > >>>> layer will save even more resources. In that case and assuming that > > >>>> all the traffic through the link have the same QoS requirements > > >>>> (for example a sensor network), the idea would be to group all the > > >>>> flows through the link (the bottleneck). > > >>>> > > >>>> Regards, > > >>>> > > >>>> Fernando Pascual Blanco > > >>>> Telefónica Global Resources > > >>>> Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F > > >>>> +34913128779 M +34682005168 fpb@tid.es > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> On 18/09/12 20:46, "Gorry Fairhurst" > wrote: > > >>>> > > >>>>>A satellite "link" may provide HC, at least some of the ones I have > > >>>>>seen do. In this case, the flows can easily be grouped by mac > > >>>>>address? > > >>>>> > > >>>>>Gorry > > >>>>> > > >>>>>On 13/09/2012 16:20, Jose Saldana wrote: > > >>>>>> Hi, Fernando, sorry for the delay (one week, I¹m afraid). > > >>>>>> > > >>>>>> I don¹t know who is the one interested on using TCMTF: > > >>>>>> > > >>>>>> -If you are a costumer, and you have to pay for a satellite link > > >>>>>>or a long distance wire, perhaps you are the one interested on > > >>>>>>using end-to-end TCMTF, since you will save bandwidth or packets > > >>>>>>per second or money. If you have e.g. two offices, one in > > >>>>>>America and other one in Europe, you may be interested on placing > > >>>>>>a device for multiplexing a number of VoIP calls between them. > > >>>>>>You have one advantage: the flows have the same origin and > > >>>>>>destination, so header compression is effective. > > >>>>>> > > >>>>>> -If you are the operator of the satellite, you have another problem: > > >>>>>> you > > >>>>>> may have to check every flow, and try to group them. Perhaps it > > >>>>>> may be easy, but if you want to save headers, you need flows with > > >>>>>> the same origin and destination. > > >>>>>> > > >>>>>> I think that there are different scenarios, and each ³actor² > > >>>>>>may try to use TCMTF in the best place: a high number of flows, > > >>>>>>with small packets, and sharing the same origin and destination. > > >>>>>> > > >>>>>> Do you agree? > > >>>>>> > > >>>>>> Jose > > >>>>>> > > >>>>>> *De:*tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] > *En > > >>>>>> nombre de *FERNANDO PASCUAL BLANCO *Enviado el:* martes, 04 de > > >>>>>> septiembre de 2012 12:27 > > >>>>>> *Para:* tcmtf@ietf.org > > >>>>>> *Asunto:* Re: [tcmtf] Discussing M2M scenario and savings > > >>>>>> > > >>>>>> Hi all, > > >>>>>> > > >>>>>> Yes, M2M sensor networks are a very good example in order to save > > >>>>>> bandwidth in long distance/big latency/low bandwidth links, links > > >>>>>> were the cost per bit is high. Do you think network carriers > > >>>>>> operating this kind of links (satellite links or long distance > > >>>>>> wires) would be interested in apply TCMTF? > > >>>>>> > > >>>>>> Regards, > > >>>>>> > > >>>>>> Fernando > > >>>>>> > > >>>>>> *From:*tcmtf-bounces@ietf.org > > >>>>>> [mailto:tcmtf-bounces@ietf.org] > > > >>>>>> > > >>>>>> *On Behalf Of *Jose Saldana > > >>>>>> *Sent:* martes, 04 de septiembre de 2012 9:41 > > >>>>>> *To:* tcmtf@ietf.org > > >>>>>> *Cc:* Matteo.Berioli@dlr.de > ; > > >>>>>> Tomaso.deCola@dlr.de > > > >>>>>> *Subject:* [tcmtf] Discussing M2M scenario and savings > > >>>>>> > > >>>>>> Hi again, > > >>>>>> > > >>>>>> We already discussed some points about the M2M scenario at the > > >>>>>>beginning of August. We are currently studying this, and we have > > >>>>>>built some figures, in collaboration with people from DLR (Tomaso > > >>>>>>and Matteo). > > >>>>>>You > > >>>>>> can find the figures here: > > >>>>>> > > >>>>>> > > >>>>>>http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_savings > > >>>>>>.pd > > >>>>>>f > > >>>>>> > > >>>>>> > > >>>>>>http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenari > > >>>>>>o.p > > >>>>>>df > > >>>>>> > > >>>>>> Perhaps we could comment them, in order to discuss this scenario, > > >>>>>> and we may find new ones in which TCMTF can be useful. > > >>>>>> > > >>>>>> Thanks, > > >>>>>> > > >>>>>> Jose > > >>>>>> > > >>>>>> > > >>>>>>------------------------------------------------------------------ > > >>>>>>--- > > >>>>>>-- > > >>>>>>- > > >>>>>> > > >>>>>> > > >>>>>> Este mensaje se dirige exclusivamente a su destinatario. Puede > > >>>>>> consultar nuestra política de envío y recepción de correo > > >>>>>> electrónico en el enlace situado más 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 > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> tcmtf mailing list > > >>>>>> tcmtf@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/tcmtf > > >>>>>> > > >>>>> > > >>>>>_______________________________________________ > > >>>>>tcmtf mailing list > > >>>>>tcmtf@ietf.org > > >>>>>https://www.ietf.org/mailman/listinfo/tcmtf > > >>>> > > >>>> > > >>>> ________________________________ > > >>>> > > >>>> Este mensaje se dirige exclusivamente a su destinatario. Puede > > >>>> consultar nuestra política de envío y recepción de correo > > >>>> electrónico en el enlace situado más 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 > > >>>> > > >>> > > >>> > > >> > > >> > > >> ________________________________ > > >> > > >> Este mensaje se dirige exclusivamente a su destinatario. Puede > > >> consultar nuestra política de envío y recepción de correo > > >> electrónico en el enlace situado más 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 > > >> > > > > > > > > > > > >_______________________________________________ > > >tcmtf mailing list > > >tcmtf@ietf.org > > >https://www.ietf.org/mailman/listinfo/tcmtf > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > nuestra pol�tica de env�o y recepci�n de correo electr�nico en el enlace > situado m�s 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 > > _______________________________________________ > > tcmtf mailing list > > tcmtf@ietf.org > > https://www.ietf.org/mailman/listinfo/tcmtf > > > > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf > From jsaldana@unizar.es Thu Sep 27 03:31:19 2012 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 AC64721F86AD for ; Thu, 27 Sep 2012 03:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.492 X-Spam-Level: X-Spam-Status: No, score=-5.492 tagged_above=-999 required=5 tests=[AWL=1.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id My8rZ1qWOgKS for ; Thu, 27 Sep 2012 03:31:19 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 98F0821F86D3 for ; Thu, 27 Sep 2012 03:31:18 -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 q8RAVDh1005458; Thu, 27 Sep 2012 12:31:13 +0200 From: "Jose Saldana" To: Date: Thu, 27 Sep 2012 12:31:18 +0200 Organization: Universidad de Zaragoza Message-ID: <007801cd9c9b$3b06d5a0$b11480e0$@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: Ac2cmrry4BaRIpi1Sm27mcZI4g4aKw== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: Wesley Eddy , Martin Stiemerling Subject: [tcmtf] Next steps with TCMTF 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, 27 Sep 2012 10:31:19 -0000 Hello all, I would like to discuss in this list the possibility of creating a small Working Group for TCMTF, as suggested by Wes. It could have the task of making a RFC from TCMTF, or a wider scope. I think that perhaps more than a draft would be necessary. I mean, I have been thinking about it, and perhaps the work could be divided into the next parts: a) "Current draft": the main draft (draft-saldana-tsvwg-tcmtf-03), including the protocol stack of TCMTF. The current proposal has different options, but the concrete one to use is static: in the set-up moment, you decide that "between these two routers a tunnel is set including all the packets with this IP origin and destination". b) "Recommendations draft": another "informational" one, with recommendations of maximum delays to be added to different kinds of services, different multiplexing policies, implementation issues related to the selection of the best compression algorithm to use, etc. Some hypothetical examples: - "if you are multiplexing a First Person Shooter, your multiplexer should not retain packets more than 50 ms" - "if you are multiplexing in a low-end router in a wired scenario, you don't need to use ROHC. A simpler scheme like IPHC can be enough, and it will not require a lot of processing capacity". c) "Dynamic Signaling draft": perhaps another one including a signaling system in order to: - dynamically "negotiate" the concrete options of TCMTF you are going to use - if two routers notice that a rush hour is arriving, they could send some packets asking other routers if they have some flows in common with them, which could be multiplexed. The main questions are: Is this enough for creating a working group? Do you think the distribution of the work into three draft makes sense? Is there any other issue which should be studied and standardized? Perhaps other people could imagine more things. So let's start the discussion. Thanks in advance, Jose From fpb@tid.es Thu Sep 27 08:09:24 2012 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 6F82921F859E for ; Thu, 27 Sep 2012 08:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.354 X-Spam-Level: X-Spam-Status: No, score=-5.354 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vA-XcufWmNuN for ; Thu, 27 Sep 2012 08:09:23 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id F112421F859C for ; Thu, 27 Sep 2012 08:09:22 -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 <0MB000IFPKRLLM@tid.hi.inet> for tcmtf@ietf.org; Thu, 27 Sep 2012 17:09:21 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 8C.48.05494.12C64605; Thu, 27 Sep 2012 17:09:21 +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 <0MB000IFIKRKLM@tid.hi.inet> for tcmtf@ietf.org; Thu, 27 Sep 2012 17:09:21 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.214]) by ex10-htcas4-mad.hi.inet ([::1]) with mapi id 14.02.0318.001; Thu, 27 Sep 2012 17:08:19 +0200 Date: Thu, 27 Sep 2012 15:08:19 +0000 From: FERNANDO PASCUAL BLANCO In-reply-to: <007801cd9c9b$3b06d5a0$b11480e0$@unizar.es> X-Originating-IP: [10.95.64.115] To: "jsaldana@unizar.es" , "tcmtf@ietf.org" Message-id: Content-id: <5473072E6A29A243931B42CD99023F0E@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [tcmtf] Next steps with TCMTF Thread-index: Ac2cmrry4BaRIpi1Sm27mcZI4g4aKwAJ1PiA user-agent: Microsoft-MacOutlook/14.2.4.120824 X-AuditID: 0a5f4e69-b7fc06d000001576-0b-50646c21ff37 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsXCFe9nqKuYkxJgcL9X2GLX5w2MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK2HV6MWPBdsmKlT8OMzcwnhLpYuTkkBAwkXh8YiczhC0mceHe erYuRi4OIYHtjBLH39xhhnB+Mkp8f7GBCaRKSGAmo8TN2/JdjBwcLAKqEv/W84KE2QS0JE7f XcUCEhYGss98UwcJcwpYSFycMRNqvoLEn3OPWUBsEYEAid0tB8BsZoEoiSNLjjKC2LwC3hIN sw6xQ8TNJDZdWM0EEReU+DH5HlS9jkTv92/MELa4RHPrTai4tsSTdxdYQWxGoF++n1rDBLFL W+Lnt09sELaRxKLXX8DmiwroSSzYfRDqNgGJJXvOQ9miEi8f/2OdwCgxC8kZs5CcMQvJGbOQ nDELyRkLGFlXMYoVJxVlpmeU5CZm5qQbGOllZOpl5qWWbGKExFzmDsblO1UOMQpwMCrx8P5Y mBAgxJpYVlyZe4hRkoNJSZQ3MzslQIgvKT+lMiOxOCO+qDQntfgQowQHs5IIb5QqUI43JbGy KrUoHyYlw8GhJME7OwsoJViUmp5akZaZA0wsMGkmDk6Qdh6g9vsgNbzFBYm5xZnpEPlTjJJS 4rxHQBICIImM0jy43leM4kBHCvPOAMnyAFMgXNcroIFMQAOXbkoCGViSiJCSamCc++WF9w6R k/ULZcMW79RdsHn7g+/WvTeO8MsJBKltb7Kt85ZsqL0iJ2ZQG5tw6vSdJdNWT7S/d6e0wDOu df3esKIUCZ8f+3Mif5+7n845Y0LDmfjZuUrzvnip+XBEP038YLLg7/m1mV5OIS5fYpv9yoOd znZeOrLvyv/bBSZLbqV+Y/w3uUhFiaU4I9FQi7moOBEAnmDG3T4DAAA= Cc: Wesley Eddy , Martin Stiemerling Subject: Re: [tcmtf] Next steps with TCMTF 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, 27 Sep 2012 15:09:24 -0000 Hi Jose, I absolutely agree with your classification. Nevertheless I miss a = draft explaining how to deal with different QoS flows passing through a TCMTF tunnel: Should we map packet marks like DiffServ to different tunnels between the same points? Could we mix some flows and under what conditions? Do you think that would be included in your second draft proposal? Regards, Fernando Pascual Blanco Telef=F3nica Global Resources Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F +34913128779 M +34682005168 fpb@tid.es On 27/09/12 12:31, "Jose Saldana" wrote: >Hello all, > >I would like to discuss in this list the possibility of creating a small >Working Group for TCMTF, as suggested by Wes. It could have the task of >making a RFC from TCMTF, or a wider scope. I think that perhaps more than >a >draft would be necessary. I mean, I have been thinking about it, and >perhaps >the work could be divided into the next parts: > > a) "Current draft": the main draft (draft-saldana-tsvwg-tcmtf-03), >including the protocol stack of TCMTF. The current proposal has different >options, but the concrete one to use is static: in the set-up moment, you >decide that "between these two routers a tunnel is set including all the >packets with this IP origin and destination". > >b) "Recommendations draft": another "informational" one, with >recommendations of maximum delays to be added to different kinds of >services, different multiplexing policies, implementation issues related >to >the selection of the best compression algorithm to use, etc. Some >hypothetical examples: > - "if you are multiplexing a First Person Shooter, your multiplexer >should not retain packets more than 50 ms" >- "if you are multiplexing in a low-end router in a wired scenario, you >don't need to use ROHC. A simpler scheme like IPHC can be enough, and it >will not require a lot of processing capacity". > >c) "Dynamic Signaling draft": perhaps another one including a signaling >system in order to: > - dynamically "negotiate" the concrete options of TCMTF you are >going to use > - if two routers notice that a rush hour is arriving, they could >send some packets asking other routers if they have some flows in common >with them, which could be multiplexed. > > >The main questions are: > >Is this enough for creating a working group? > >Do you think the distribution of the work into three draft makes sense? > >Is there any other issue which should be studied and standardized? Perhaps >other people could imagine more things. > >So let's start the discussion. > >Thanks in advance, > >Jose > > >_______________________________________________ >tcmtf mailing list >tcmtf@ietf.org >https://www.ietf.org/mailman/listinfo/tcmtf ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx From gonzalo.camarillo@ericsson.com Thu Sep 27 08:33:27 2012 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 E119C21F84A6 for ; Thu, 27 Sep 2012 08:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.218 X-Spam-Level: X-Spam-Status: No, score=-106.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGNpeOyGau9V for ; Thu, 27 Sep 2012 08:33:27 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8517A21F84BF for ; Thu, 27 Sep 2012 08:33:26 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-5f-506471c54768 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 01.85.25676.5C174605; Thu, 27 Sep 2012 17:33:25 +0200 (CEST) Received: from [131.160.126.221] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.1; Thu, 27 Sep 2012 17:33:25 +0200 Message-ID: <506471C4.2060903@ericsson.com> Date: Thu, 27 Sep 2012 18:33:24 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: FERNANDO PASCUAL BLANCO References: In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvre7RwpQAgyV/1C3OnrvHYrHlmJ5F R99VNotdnzcwWlz/zu7A6rFkyU8mj5Onetk8Zhx7ye7x5O8WZo9lV48wB7BGcdmkpOZklqUW 6dslcGWcvbqfreCcXMX3xlnMDYxbJboYOTgkBEwktn2o6mLkBDLFJC7cW8/WxcjFISRwilFi 243NUM5aRok5zUuZQKp4BbQltt3/wA7SzCKgKrGnhwckzCZgIbHl1n0WEFtUIFji3MZtbBDl ghInZz4Bi4sIaEhsv/uXGWQms8A6RokZh84xgswRFtCSOPNNHaRGSMBbYnpnByuIzSngIzFj bysLxHGSEm8m3wSzmQX0JKZcbWGEsOUlmrfOZobo1ZZY/qyFZQKj0Cwkq2chaZmFpGUBI/Mq RuHcxMyc9HIjvdSizOTi4vw8veLUTYzAwD+45bfqDsY750QOMUpzsCiJ81pv3eMvJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgXGti8PVMF4pje+7Zm6f2fXrs0su61zL9sz/dVlfPM/c2DG9 7SXv17MvX/AuMojpfeeYPk87qtzIaNdkzcePLHYLKn6z2Mb92O0iq8iDstnzlwZ1vHhiEPas /rnk/MV2fmHL9WNkLqw9VPqWa9PBXL6nf1axSnnre0z5q7TxbF78MYd5V0LXRLYpsRRnJBpq MRcVJwIAmDfuU0oCAAA= Cc: "tcmtf@ietf.org" , Wesley Eddy , Martin Stiemerling , "jsaldana@unizar.es" Subject: Re: [tcmtf] Next steps with TCMTF 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, 27 Sep 2012 15:33:28 -0000 Hi Jose Maria, if the idea is to create a WG to work on these drafts, what you need to do is to propose a draft charter, polish it on this list, and then present it to Wes and Martin at some point so that they can create the WG. You have many examples of charters on the IETF WG pages, of course. Cheers, Gonzalo On 27/09/2012 6:08 PM, FERNANDO PASCUAL BLANCO wrote: > Hi Jose, > > I absolutely agree with your classification. Nevertheless I miss a draft > explaining how to deal with different QoS flows passing through a TCMTF > tunnel: Should we map packet marks like DiffServ to different tunnels > between the same points? Could we mix some flows and under what > conditions? Do you think that would be included in your second draft > proposal? > > Regards, > > Fernando Pascual Blanco > Telef�nica Global Resources > Network Automation and Dynamization > TECHNOLOGY PEOPLE GROUP > F +34913128779 > M +34682005168 > fpb@tid.es > > > > > On 27/09/12 12:31, "Jose Saldana" wrote: > >> Hello all, >> >> I would like to discuss in this list the possibility of creating a small >> Working Group for TCMTF, as suggested by Wes. It could have the task of >> making a RFC from TCMTF, or a wider scope. I think that perhaps more than >> a >> draft would be necessary. I mean, I have been thinking about it, and >> perhaps >> the work could be divided into the next parts: >> >> a) "Current draft": the main draft (draft-saldana-tsvwg-tcmtf-03), >> including the protocol stack of TCMTF. The current proposal has different >> options, but the concrete one to use is static: in the set-up moment, you >> decide that "between these two routers a tunnel is set including all the >> packets with this IP origin and destination". >> >> b) "Recommendations draft": another "informational" one, with >> recommendations of maximum delays to be added to different kinds of >> services, different multiplexing policies, implementation issues related >> to >> the selection of the best compression algorithm to use, etc. Some >> hypothetical examples: >> - "if you are multiplexing a First Person Shooter, your multiplexer >> should not retain packets more than 50 ms" >> - "if you are multiplexing in a low-end router in a wired scenario, you >> don't need to use ROHC. A simpler scheme like IPHC can be enough, and it >> will not require a lot of processing capacity". >> >> c) "Dynamic Signaling draft": perhaps another one including a signaling >> system in order to: >> - dynamically "negotiate" the concrete options of TCMTF you are >> going to use >> - if two routers notice that a rush hour is arriving, they could >> send some packets asking other routers if they have some flows in common >> with them, which could be multiplexed. >> >> >> The main questions are: >> >> Is this enough for creating a working group? >> >> Do you think the distribution of the work into three draft makes sense? >> >> Is there any other issue which should be studied and standardized? Perhaps >> other people could imagine more things. >> >> So let's start the discussion. >> >> Thanks in advance, >> >> Jose >> >> >> _______________________________________________ >> tcmtf mailing list >> tcmtf@ietf.org >> https://www.ietf.org/mailman/listinfo/tcmtf > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol�tica de env�o y recepci�n de correo electr�nico en el enlace situado m�s 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 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf > From jsaldana@unizar.es Thu Sep 27 08:52:56 2012 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 6765521F8608 for ; Thu, 27 Sep 2012 08:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.631 X-Spam-Level: X-Spam-Status: No, score=-5.631 tagged_above=-999 required=5 tests=[AWL=0.968, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqJAXXreIBrj for ; Thu, 27 Sep 2012 08:52:54 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFED21F85BB for ; Thu, 27 Sep 2012 08:52:54 -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 q8RFqkgF025897; Thu, 27 Sep 2012 17:52:46 +0200 From: "Jose Saldana" To: "'Gonzalo Camarillo'" References: <506471C4.2060903@ericsson.com> In-Reply-To: <506471C4.2060903@ericsson.com> Date: Thu, 27 Sep 2012 17:52:52 +0200 Organization: Universidad de Zaragoza Message-ID: <001201cd9cc8$27769ed0$7663dc70$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIHFRKZSO0nX1/yg8lkCOc+5IJ3+wIKLOzolxsTyUA= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org Subject: Re: [tcmtf] Next steps with TCMTF 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, 27 Sep 2012 15:52:56 -0000 Thanks, Gonzalo. As you suggest, a good approach could be hearing and discussing people's opinions about the work to be deployed, and build a charter with that. I think that next week I could build a first version of the charter, = and then we could polish it on the list. Thank you, Jose > -----Mensaje original----- > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre = de > Gonzalo Camarillo > Enviado el: jueves, 27 de septiembre de 2012 17:33 > Para: FERNANDO PASCUAL BLANCO > CC: tcmtf@ietf.org; Wesley Eddy; Martin Stiemerling; = jsaldana@unizar.es > Asunto: Re: [tcmtf] Next steps with TCMTF >=20 > Hi Jose Maria, >=20 > if the idea is to create a WG to work on these drafts, what you need = to do is > to propose a draft charter, polish it on this list, and then present = it to Wes > and Martin at some point so that they can create the WG. >=20 > You have many examples of charters on the IETF WG pages, of course. >=20 > Cheers, >=20 > Gonzalo >=20 > On 27/09/2012 6:08 PM, FERNANDO PASCUAL BLANCO wrote: > > Hi Jose, > > > > I absolutely agree with your classification. Nevertheless I > > miss a draft explaining how to deal with different QoS flows passing > > through a TCMTF > > tunnel: Should we map packet marks like DiffServ to different = tunnels > > between the same points? Could we mix some flows and under what > > conditions? Do you think that would be included in your second draft > > proposal? > > > > Regards, > > > > Fernando Pascual Blanco > > Telef=F3nica Global Resources > > Network Automation and Dynamization > > TECHNOLOGY PEOPLE GROUP > > F +34913128779 > > M +34682005168 > > fpb@tid.es > > > > > > > > > > On 27/09/12 12:31, "Jose Saldana" wrote: > > > >> Hello all, > >> > >> I would like to discuss in this list the possibility of creating a > >> small Working Group for TCMTF, as suggested by Wes. It could have = the > >> task of making a RFC from TCMTF, or a wider scope. I think that > >> perhaps more than a draft would be necessary. I mean, I have been > >> thinking about it, and perhaps the work could be divided into the > >> next parts: > >> > >> a) "Current draft": the main draft (draft-saldana-tsvwg-tcmtf-03), > >> including the protocol stack of TCMTF. The current proposal has > >> different options, but the concrete one to use is static: in the > >> set-up moment, you decide that "between these two routers a tunnel = is > >> set including all the packets with this IP origin and destination". > >> > >> b) "Recommendations draft": another "informational" one, with > >> recommendations of maximum delays to be added to different kinds of > >> services, different multiplexing policies, implementation issues > >> related to the selection of the best compression algorithm to use, > >> etc. Some hypothetical examples: > >> - "if you are multiplexing a First Person Shooter, your > >> multiplexer should not retain packets more than 50 ms" > >> - "if you are multiplexing in a low-end router in a wired scenario, > >> you don't need to use ROHC. A simpler scheme like IPHC can be = enough, > >> and it will not require a lot of processing capacity". > >> > >> c) "Dynamic Signaling draft": perhaps another one including a > >> signaling system in order to: > >> - dynamically "negotiate" the concrete options of TCMTF you = are > >> going to use > >> - if two routers notice that a rush hour is arriving, they > >> could send some packets asking other routers if they have some = flows > >> in common with them, which could be multiplexed. > >> > >> > >> The main questions are: > >> > >> Is this enough for creating a working group? > >> > >> Do you think the distribution of the work into three draft makes = sense? > >> > >> Is there any other issue which should be studied and standardized? > >> Perhaps other people could imagine more things. > >> > >> So let's start the discussion. > >> > >> Thanks in advance, > >> > >> Jose > >> > >> > >> _______________________________________________ > >> tcmtf mailing list > >> tcmtf@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcmtf > > > > > > ________________________________ > > > > Este mensaje se dirige exclusivamente a su destinatario. Puede = consultar > nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en = el enlace > situado m=E1s abajo. > > This message is intended exclusively for its addressee. We only send = and > receive email on the basis of the terms set out at: > > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > > _______________________________________________ > > tcmtf mailing list > > tcmtf@ietf.org > > https://www.ietf.org/mailman/listinfo/tcmtf > > >=20 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf From jsaldana@unizar.es Fri Sep 28 02:17:17 2012 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 7D05321F8516 for ; Fri, 28 Sep 2012 02:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.738 X-Spam-Level: X-Spam-Status: No, score=-5.738 tagged_above=-999 required=5 tests=[AWL=0.860, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucT4Nklv9JNX for ; Fri, 28 Sep 2012 02:17:17 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id A1CE021F84F3 for ; Fri, 28 Sep 2012 02:17:16 -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 q8S9HC25011503 for ; Fri, 28 Sep 2012 11:17:12 +0200 From: "Jose Saldana" To: Date: Fri, 28 Sep 2012 11:17:17 +0200 Organization: Universidad de Zaragoza Message-ID: <000e01cd9d5a$0e3f2850$2abd78f0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01CD9D6A.D1C7F850" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2dWc3roSS93utvTYC2TKQuzRqQgw== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: [tcmtf] TCMTF: two kinds of services 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, 28 Sep 2012 09:17:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000F_01CD9D6A.D1C7F850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is another thought to be discussed. We can have two different situations for multiplexing flows: - delay-sensitive services (e.g., VoIP, online games). In this case, TCMTF would add some delay, so it should only be used when bandwidth is scarce (rush hours, new game release, etc.). If your network is working properly, why do you need to save bandwidth and add a small delay to the clients? So in rush hours there must be a counterpart in order to add some priority to the tunneled packets. Otherwise you would penalize them: since they are small and can be multiplexed, they are delayed. - services sending small packets but not delay-sensitive (e.g., whatsapp, m2m packets being generated every second). In this case TCMTF saves bandwidth while adding some delay, but it is not critical. Jose ------=_NextPart_000_000F_01CD9D6A.D1C7F850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This is another thought to be discussed. We can have two = different situations for multiplexing flows:

- delay-sensitive services = (e.g., VoIP, online games). In this case, TCMTF would add some delay, so = it should only be used when bandwidth is scarce (rush hours, new game = release, etc.). If your network is working properly, why do you need to = save bandwidth and add a small delay to the clients? So in rush hours = there must be a counterpart in order to add some priority to the = tunneled packets. Otherwise you would penalize them: since they are = small and can be multiplexed, they are delayed.

- services sending small packets = but not delay-sensitive (e.g., whatsapp, m2m packets being generated = every second). In this case TCMTF saves bandwidth while adding some = delay, but it is not critical.

Jose

------=_NextPart_000_000F_01CD9D6A.D1C7F850-- From jsaldana@unizar.es Fri Sep 28 02:19:29 2012 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 D827B21F851C for ; Fri, 28 Sep 2012 02:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.824 X-Spam-Level: X-Spam-Status: No, score=-5.824 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUh8j-f7zLKj for ; Fri, 28 Sep 2012 02:19:28 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 94EA721F8516 for ; Fri, 28 Sep 2012 02:19:28 -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 q8S9JOdN029356; Fri, 28 Sep 2012 11:19:24 +0200 From: "Jose Saldana" To: "'FERNANDO PASCUAL BLANCO'" References: <007801cd9c9b$3b06d5a0$b11480e0$@unizar.es> In-Reply-To: Date: Fri, 28 Sep 2012 11:19:29 +0200 Organization: Universidad de Zaragoza Message-ID: <001c01cd9d5a$5d104fe0$1730efa0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIHFRKZSO0nX1/yg8lkCOc+5IJ3+5crZlYA Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org Subject: Re: [tcmtf] Next steps with TCMTF 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, 28 Sep 2012 09:19:30 -0000 Fernando, I have been thinking about it. There are three questions: A) Should we map packet marks like DiffServ to different tunnels between = the same points? There is a first question: it does not exist (by now) a universally = accepted standard about Diffserv mapping for different services. Perhaps an ISP = may have a clear classification, so it can be useful for this, if the tunnel = is created inside his aggregation network. Although marking can be useful, perhaps it would not be enough: if you = want to group the packets of a certain game, and establish a tunnel finishing = at the game server, you need to identify them by the destination IP. So I = think you would need something more than Diffserv. My proposal: including in the draft b) a sentence like "Different = mechanisms can be used in order to decide which packets are included into each = tunnel. For example, Diffserv can be useful when doing this. In other cases, the packet flows would have to be identified by their origin and/or = destination IP addresses." Fernando (and people from network operators): please think about this. = As network providers, you should have a clearer idea about this. B) Could we mix some flows and under what conditions? If the tunnel is only set inside the ISP network, or between two ISPs, = then I think there is no problem on grouping packets from different services, = or even transport protocols (UDP and TCP flows in the same tunnel). The question is that you have to accomplish the delay requirements of the = most delay-sensitive service. As we have three layers (compressing, multiplexing, tunneling), I think = that tunneling and multiplexing layers do not have to know which kind of = packet they are carrying. (I am posting another message about this). Other question is: if you can set up a tunnel covering the whole route (e.g., from the access network to the game server), then you can only = group packets of a single game. On the other hand, if you only group packets = in your aggregation network, you can group a big number of flows. When the tunnel arrives at the internet router, the packets are rebuilt and sent = in their native form. So the longer the common route you want to cover, the more specific = traffic you can tunnel. C) Do you think that would be included in your second draft proposal? By now, I think this can be issued in draft b). However, we have to = further think about it. Thank you, Jose =20 > -----Mensaje original----- > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre = de > FERNANDO PASCUAL BLANCO > Enviado el: jueves, 27 de septiembre de 2012 17:08 > Para: jsaldana@unizar.es; tcmtf@ietf.org > CC: Wesley Eddy; Martin Stiemerling > Asunto: Re: [tcmtf] Next steps with TCMTF >=20 > Hi Jose, >=20 > I absolutely agree with your classification. Nevertheless I = miss a draft > explaining how to deal with different QoS flows passing through a = TCMTF > tunnel: Should we map packet marks like DiffServ to different tunnels > between the same points? Could we mix some flows and under what > conditions? Do you think that would be included in your second draft > proposal? >=20 > Regards, >=20 > Fernando Pascual Blanco > Telef=F3nica Global Resources > Network Automation and Dynamization > TECHNOLOGY PEOPLE GROUP > F +34913128779 > M +34682005168 > fpb@tid.es >=20 >=20 >=20 >=20 > On 27/09/12 12:31, "Jose Saldana" wrote: >=20 > >Hello all, > > > >I would like to discuss in this list the possibility of creating a > >small Working Group for TCMTF, as suggested by Wes. It could have the > >task of making a RFC from TCMTF, or a wider scope. I think that = perhaps > >more than a draft would be necessary. I mean, I have been thinking > >about it, and perhaps the work could be divided into the next parts: > > > > a) "Current draft": the main draft (draft-saldana-tsvwg-tcmtf-03), > >including the protocol stack of TCMTF. The current proposal has > >different options, but the concrete one to use is static: in the = set-up > >moment, you decide that "between these two routers a tunnel is set > >including all the packets with this IP origin and destination". > > > >b) "Recommendations draft": another "informational" one, with > >recommendations of maximum delays to be added to different kinds of > >services, different multiplexing policies, implementation issues > >related to the selection of the best compression algorithm to use, = etc. > >Some hypothetical examples: > > - "if you are multiplexing a First Person Shooter, your > >multiplexer should not retain packets more than 50 ms" > >- "if you are multiplexing in a low-end router in a wired scenario, = you > >don't need to use ROHC. A simpler scheme like IPHC can be enough, and > >it will not require a lot of processing capacity". > > > >c) "Dynamic Signaling draft": perhaps another one including a = signaling > >system in order to: > > - dynamically "negotiate" the concrete options of TCMTF you = are > >going to use > > - if two routers notice that a rush hour is arriving, they = could > >send some packets asking other routers if they have some flows in > >common with them, which could be multiplexed. > > > > > >The main questions are: > > > >Is this enough for creating a working group? > > > >Do you think the distribution of the work into three draft makes = sense? > > > >Is there any other issue which should be studied and standardized? > >Perhaps other people could imagine more things. > > > >So let's start the discussion. > > > >Thanks in advance, > > > >Jose > > > > > >_______________________________________________ > >tcmtf mailing list > >tcmtf@ietf.org > >https://www.ietf.org/mailman/listinfo/tcmtf >=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 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf From jsaldana@unizar.es Fri Sep 28 02:39:25 2012 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 232DB21F85B1 for ; Fri, 28 Sep 2012 02:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.894 X-Spam-Level: X-Spam-Status: No, score=-6.894 tagged_above=-999 required=5 tests=[AWL=1.704, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miqjjUJK6Clu for ; Fri, 28 Sep 2012 02:39:24 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id F24C521F8578 for ; Fri, 28 Sep 2012 02:39:23 -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 q8S9dEqp003269 for ; Fri, 28 Sep 2012 11:39:14 +0200 From: "Jose Saldana" To: Date: Fri, 28 Sep 2012 11:39:21 +0200 Organization: Universidad de Zaragoza Message-ID: <001d01cd9d5d$239aa870$6acff950$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01CD9D6D.E7243BC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2dWmmuh0nyfojQS3ewOn6+GV2BHg== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: [tcmtf] TCMTF: The importance of the layers 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, 28 Sep 2012 09:39:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001E_01CD9D6D.E7243BC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit (this message has to be seen in Courier letters) We have three different layers: Header compression | Multiplexing | Tunneling This allows us to do things like these: - Adding a new flow to a currently existing tunnel: you can merge two tunnels coming from different aggregators: You only have to rebuild the multiplexing and tunneling, but it would not affect header compression. The problem here could be the added delays in each aggregator. Perhaps a synchronization could be deployed in order to receive packets from different tunnels just at the same time. +------------+ 5 flows tunnel ----->| | | aggregator | ----------> 12 flows tunnel 7 flows tunnel ----->| | +------------+ The aggregator does not implement or use header compression If the two arriving tunnels were synchronized, then the aggregator would only add processing delay - Changing the tunneling protocol without modifying multiplexing or header compression: in a device you could modify the tunneling header, substituting it by other tunneling protocol. One question: could this be done, when arriving to a MPLS network? Should the L2TP/IP headers be maintained?: +------+-------+ | L2TP | + 5 flows tunnel --> +------+ MPLS + ----------> 5 flows tunnel | IP | + +------+-------+ What do you think? Are these things implicit in the method, or should we also include them in the draft(s)? Thanks, Jose ------=_NextPart_000_001E_01CD9D6D.E7243BC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
(this message has to be = seen in Courier letters)

We have three different = layers:

Header compression
     |
Multiplexing
     |
Tunneling

This allows us to do = things like these:

- Adding a new flow to = a currently existing tunnel: you can merge two tunnels coming from = different aggregators: You only have to rebuild the multiplexing and = tunneling, but it would not affect header compression. The problem here = could be the added delays in each aggregator. Perhaps a synchronization = could be deployed in order to receive packets from different tunnels = just at the same time.

           &= nbsp; =        +------------+
5 flows tunnel = ----->|   =          |=
   =             &= nbsp;     | aggregator | ----------> = 12 flows tunnel
7 flows tunnel = ----->| =            |<= /o:p>
           &= nbsp; =        +------------+

          The = aggregator does not implement or use header = compression
          If the two = arriving tunnels were synchronized, then the aggregator would only add = processing delay

- Changing the = tunneling protocol without modifying multiplexing or header compression: = in a device you could modify the tunneling header, substituting it by = other tunneling protocol.

One question: could = this be done, when arriving to a MPLS network? Should the L2TP/IP = headers be maintained?:

           &= nbsp; =       +------+-------+
           &= nbsp;       | L2TP = |       +
5 flows tunnel --> +------+ MPLS + = ----------> 5 flows = tunnel
           &= nbsp;       | IP   = |       +
           &= nbsp; =       +------+-------+

What do you think? Are = these things implicit in the method, or should we also include them in = the draft(s)?

Thanks,

Jose =

------=_NextPart_000_001E_01CD9D6D.E7243BC0-- From jsaldana@unizar.es Fri Sep 28 03:19:48 2012 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 DA60521F844C for ; Fri, 28 Sep 2012 03:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.037 X-Spam-Level: X-Spam-Status: No, score=-6.037 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryJbAPZSCqw3 for ; Fri, 28 Sep 2012 03:19:46 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3606D21F859E for ; Fri, 28 Sep 2012 03:19: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 q8SAJVm0011652; Fri, 28 Sep 2012 12:19:37 +0200 From: "Jose Saldana" To: , "'FERNANDO PASCUAL BLANCO'" , , , Date: Fri, 28 Sep 2012 12:19:39 +0200 Organization: Universidad de Zaragoza Message-ID: <003101cd9d62$c803f1f0$580bd5d0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2dYUy6uVqP4M0WSN+HUIzF9jzvbA== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org Subject: Re: [tcmtf] More satellite scenarios 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, 28 Sep 2012 10:19:49 -0000 We have to continue the discussion about satellite scenarios with sensor networks: if possible, I would like to hear the opinion of people from = DLR about this. However, I have found more satellite-related scenarios in which a number = of small-packet flows can be present: - A cruise: lots of people (3800 people in Queen Mary 2) connected = through a satellite link http://www.cruisemates.com/articles/onboard/connected.cfm#axzz27l0sEqu3 http://en.wikipedia.org/wiki/RMS_Queen_Mary_2 http://www.esa.int/esaTE/SEMMAWNFGLE_index_0.html - A plane: similar to the ship, but less people and no satellite, but = ground antennas communicating with a special antenna on the plane (VoIP is prohibited by now): http://en.wikipedia.org/wiki/Gogo_Inflight_Internet - Satellite access in low-populated regions (e.g. Alaska): Perhaps a = number of people, or a village, may share a connection through an antenna: http://www.skycasters.com/satellite-internet-coverage/skycasters-coverage= -Al aska.html What do you think? Best regards, Jose > -----Mensaje original----- > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre = de > Gorry Fairhurst > Enviado el: viernes, 21 de septiembre de 2012 10:29 > Para: jsaldana@unizar.es > CC: tcmtf@ietf.org; 'FERNANDO PASCUAL BLANCO' > Asunto: Re: [tcmtf] Discussing M2M scenario and savings - continuing = the > thread >=20 > I think *IF* the satellite link is a DVB 2nd generation RF link, e.g. > DVB-S2 for satellite ( a common waveform), then GSE + RFC 5163 is a > reasonable proposal, on which one may benefit if one layers a HC = scheme, > such as ROHC, or 6LoWPAN. The profile for the ROHC schemes have not > been specified for this type of link - but the relevant RFCs exist for = the > compression itself. RFC 3135 and RFC 3449 also describe TCP/IP = techniques to > help improve efficiency on such links. >=20 > As I said, I do not see the *benefit* for the mux and demux in the scenario > as drawn, since this seems more like *link* HC, and it would seem = foolish to > form aggregate traffic over a single link layer in the way that tunnel > compression implements this. >=20 > If the drawing extended the network on one or both sides of the = satellite > link, there could be a reason for using tunnel HC, although I am not = sure > whether this is commercially important, since unlike an access = network, the > connectivity to the hub (usually known as the satellite gateway) on = the left of > the figure is not usually a low speed access link and the merits of HC = is less > obvious where bandwidth is high. Also, it would seem desirable to use > encapsulation and HC mechanisms on the satellite air interface anyway, = RFC > 3135 part 3 (from the source), possibly combined with RFC 3449 = mechanisms. >=20 > All I am saying is you have to be sure to describe the scenario = carefully and > explain why HC applies in this case and what alternatives exist. >=20 > Gorry >=20 > On 20/09/2012 17:20, Jose Saldana wrote: > > So, do you think the figure should be modified? Perhaps it is > > currently confusing, since it seems that RFC 5163 is the best > > solution. Perhaps a network should be included between the demux and > > the data center? Or between the antenna and the demux? Will this be = a > > real case? I don't know if in the right side it is possible to find other > networks. > > > > I am talking about this figure: > > > > = http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenario.pd > > f > > > > Thanks, > > > > Jose > > > > -----Mensaje original----- > > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre > > de FERNANDO PASCUAL BLANCO Enviado el: mi=E9rcoles, 19 de septiembre > de > > 2012 13:02 > > Para: gorry@erg.abdn.ac.uk; tcmtf@ietf.org > > Asunto: Re: [tcmtf] Discussing M2M scenario and savings - continuing > > the thread > > > > Hi Gorry, > > > > Absolutely. The tunneling layer would increase that benefit > > in a multi-router hop path, being the satellite-link part of this = path. > > > > Regards, > > > > Fernando Pascual Blanco > > > > Telef=F3nica Global Resources > > > > Network Automation and Dynamization > > > > TECHNOLOGY PEOPLE GROUP > > > > F +34913128779 > > > > M +34682005168 > > > > fpb@tid.es > > > > On 19/09/12 12:37, "gorry@erg.abdn.ac.uk > " > > > wrote: > > > > > > > > > >For a point-to-point link carrying traffic destined to a ingle L2 > > > > >address, I don't see how this helps above the gains of ROHC or = some > > > > >other HC on the link, when possibly combining this with link layer > > > > >transmission options e.g. methods like PDU-CONCAT in RFC 5163. > > > > > > > > > >If you're working over a multi-router network hop, the > > considerations > > > > >may be different. > > > > > > > > > >Gorry > > > > > > > > > >> Hi Gorry, > > > > >> > > > > >> I don=C2=B4t know a lot about link layer HC, but I = imagine that > > > > >> it compress packet headers (IP-TCP/UDP). If, in addition to = that, > > we > > > > >> group several small packets into a bigger one (using PPP-Mux and > > > > >> RoHC), don=C2=B4t you think more resources could be saved? > > > > >> > > > > >> Regards, > > > > >> > > > > >> Fernando Pascual Blanco > > > > >> Telef=C3=B3nica Global Resources > > > > >> Network Automation and Dynamization > > > > >> TECHNOLOGY PEOPLE GROUP > > > > >> F +34913128779 > > > > >> M +34682005168 > > > > >> fpb@tid.es > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> On 19/09/12 10:56, "gorry@erg.abdn.ac.uk > > " > > wrote: > > > > >> > > > > >>>I know there are applications for tunnel compression - but I'm = not > > > > >>>sure I understand how this can gain further than for link-layer = HC? > > > > >>> > > > > >>>Gorry > > > > >>> > > > > >>>> Hi Gorry, > > > > >>>> > > > > >>>> In addition of HC (header compression), the = multiplexing > > > > >>>> layer will save even more resources. In that case and assuming > > that > > > > >>>> all the traffic through the link have the same QoS = requirements > > > > >>>> (for example a sensor network), the idea would be to group all > > the > > > > >>>> flows through the link (the bottleneck). > > > > >>>> > > > > >>>> Regards, > > > > >>>> > > > > >>>> Fernando Pascual Blanco > > > > >>>> Telef=C3=B3nica Global Resources > > > > >>>> Network Automation and Dynamization TECHNOLOGY PEOPLE > GROUP F > > > > >>>> +34913128779 M +34682005168 fpb@tid.es > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> On 18/09/12 20:46, "Gorry Fairhurst" > > wrote: > > > > >>>> > > > > >>>>>A satellite "link" may provide HC, at least some of the ones I > > have > > > > >>>>>seen do. In this case, the flows can easily be grouped by mac > > > > >>>>>address? > > > > >>>>> > > > > >>>>>Gorry > > > > >>>>> > > > > >>>>>On 13/09/2012 16:20, Jose Saldana wrote: > > > > >>>>>> Hi, Fernando, sorry for the delay (one week, I=C2=B9m = afraid). > > > > >>>>>> > > > > >>>>>> I don=C2=B9t know who is the one interested on using TCMTF: > > > > >>>>>> > > > > >>>>>> -If you are a costumer, and you have to pay for a satellite > > link > > > > >>>>>>or a long distance wire, perhaps you are the one interested > > on > > > > >>>>>>using end-to-end TCMTF, since you will save bandwidth or > > packets > > > > >>>>>>per second or money. If you have e.g. two offices, one in > > > > >>>>>>America and other one in Europe, you may be interested on > > placing > > > > >>>>>>a device for multiplexing a number of VoIP calls between = them. > > > > >>>>>>You have one advantage: the flows have the same origin and > > > > >>>>>>destination, so header compression is effective. > > > > >>>>>> > > > > >>>>>> -If you are the operator of the satellite, you have another > problem: > > > > >>>>>> you > > > > >>>>>> may have to check every flow, and try to group them. Perhaps > > it > > > > >>>>>> may be easy, but if you want to save headers, you need flows > > with > > > > >>>>>> the same origin and destination. > > > > >>>>>> > > > > >>>>>> I think that there are different scenarios, and each = =C2=B3actor=C2=B2 > > > > >>>>>>may try to use TCMTF in the best place: a high number of > > flows, > > > > >>>>>>with small packets, and sharing the same origin and destination. > > > > >>>>>> > > > > >>>>>> Do you agree? > > > > >>>>>> > > > > >>>>>> Jose > > > > >>>>>> > > > > >>>>>> *De:*tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] > > *En > > > > >>>>>> nombre de *FERNANDO PASCUAL BLANCO *Enviado el:* martes, > 04 de > > > > >>>>>> septiembre de 2012 12:27 > > > > >>>>>> *Para:* tcmtf@ietf.org > > > > >>>>>> *Asunto:* Re: [tcmtf] Discussing M2M scenario and savings > > > > >>>>>> > > > > >>>>>> Hi all, > > > > >>>>>> > > > > >>>>>> Yes, M2M sensor networks are a very good example in order to > > save > > > > >>>>>> bandwidth in long distance/big latency/low bandwidth links, > > links > > > > >>>>>> were the cost per bit is high. Do you think network carriers > > > > >>>>>> operating this kind of links (satellite links or long = distance > > > > >>>>>> wires) would be interested in apply TCMTF? > > > > >>>>>> > > > > >>>>>> Regards, > > > > >>>>>> > > > > >>>>>> Fernando > > > > >>>>>> > > > > >>>>>> *From:*tcmtf-bounces@ietf.org bounces@ietf.org> > > > > >>>>>> [mailto:tcmtf-bounces@ietf.org] > > > > > > >>>>>> > > > > >>>>>> *On Behalf Of *Jose Saldana > > > > >>>>>> *Sent:* martes, 04 de septiembre de 2012 9:41 > > > > >>>>>> *To:* tcmtf@ietf.org > > > > > > >>>>>> *Cc:* Matteo.Berioli@dlr.de > > ; > > > > >>>>>> Tomaso.deCola@dlr.de > > > > > > >>>>>> *Subject:* [tcmtf] Discussing M2M scenario and savings > > > > >>>>>> > > > > >>>>>> Hi again, > > > > >>>>>> > > > > >>>>>> We already discussed some points about the M2M scenario at = the > > > > >>>>>>beginning of August. We are currently studying this, and we > > have > > > > >>>>>>built some figures, in collaboration with people from DLR > > (Tomaso > > > > >>>>>>and Matteo). > > > > >>>>>>You > > > > >>>>>> can find the figures here: > > > > >>>>>> > > > > >>>>>> > > > > > > > >>>>>>http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_savin > > gs > > > > >>>>>>.pd > > > > >>>>>>f > > > > >>>>>> > > > > >>>>>> > > > > > > > >>>>>>http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scena > > ri > > > > >>>>>>o.p > > > > >>>>>>df > > > > >>>>>> > > > > >>>>>> Perhaps we could comment them, in order to discuss this > > scenario, > > > > >>>>>> and we may find new ones in which TCMTF can be useful. > > > > >>>>>> > > > > >>>>>> Thanks, > > > > >>>>>> > > > > >>>>>> Jose > > > > >>>>>> > > > > >>>>>> > > > > > > = >>>>>>---------------------------------------------------------------- > > -- > > > > >>>>>>--- > > > > >>>>>>-- > > > > >>>>>>- > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Este mensaje se dirige exclusivamente a su destinatario. = Puede > > > > >>>>>> consultar nuestra pol=C3=ADtica de env=C3=ADo y = recepci=C3=B3n de correo > > > > >>>>>> electr=C3=B3nico en el enlace situado m=C3=A1s 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 > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> _______________________________________________ > > > > >>>>>> tcmtf mailing list > > > > >>>>>> tcmtf@ietf.org > > > > >>>>>> https://www.ietf.org/mailman/listinfo/tcmtf > > > > >>>>>> > > > > >>>>> > > > > >>>>>_______________________________________________ > > > > >>>>>tcmtf mailing list > > > > >>>>>tcmtf@ietf.org > > > > >>>>>https://www.ietf.org/mailman/listinfo/tcmtf > > > > >>>> > > > > >>>> > > > > >>>> ________________________________ > > > > >>>> > > > > >>>> Este mensaje se dirige exclusivamente a su destinatario. Puede > > > > >>>> consultar nuestra pol=C3=ADtica de env=C3=ADo y recepci=C3=B3n = de correo > > > > >>>> electr=C3=B3nico en el enlace situado m=C3=A1s 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 > > > > >>>> > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > >> ________________________________ > > > > >> > > > > >> Este mensaje se dirige exclusivamente a su destinatario. Puede > > > > >> consultar nuestra pol=C3=ADtica de env=C3=ADo y recepci=C3=B3n = de correo > > > > >> electr=C3=B3nico en el enlace situado m=C3=A1s 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 > > > > >> > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > >tcmtf mailing list > > > > >tcmtf@ietf.org > > > > >https://www.ietf.org/mailman/listinfo/tcmtf > > > > ________________________________ > > > > Este mensaje se dirige exclusivamente a su destinatario. Puede > > consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo = electr=F3nico > > en el enlace situado m=E1s abajo. > > > > This message is intended exclusively for its addressee. We only send > > and receive email on the basis of the terms set out at: > > > > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > > > > _______________________________________________ > > > > tcmtf mailing list > > > > tcmtf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/tcmtf > > > > > > > > _______________________________________________ > > tcmtf mailing list > > tcmtf@ietf.org > > https://www.ietf.org/mailman/listinfo/tcmtf > > >=20 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf From fpb@tid.es Fri Sep 28 04:20:23 2012 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 A35FA21F85D5 for ; Fri, 28 Sep 2012 04:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.058 X-Spam-Level: X-Spam-Status: No, score=-6.058 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzTC5MJOHsFu for ; Fri, 28 Sep 2012 04:20:22 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2F1B21F860E for ; Fri, 28 Sep 2012 04:20:21 -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 <0MB200CUA4TVOA@tid.hi.inet> for tcmtf@ietf.org; Fri, 28 Sep 2012 13:20:19 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 3D.1F.03050.3F785605; Fri, 28 Sep 2012 13:20:19 +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 <0MB200CU64TVOA@tid.hi.inet> for tcmtf@ietf.org; Fri, 28 Sep 2012 13:20:19 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.209]) by ex10-htcas3-mad.hi.inet ([::1]) with mapi id 14.02.0318.001; Fri, 28 Sep 2012 13:19:17 +0200 Date: Fri, 28 Sep 2012 11:20:18 +0000 From: FERNANDO PASCUAL BLANCO In-reply-to: <000e01cd9d5a$0e3f2850$2abd78f0$@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_VdLchu7ujyo1RXp4EZPRHw)" Content-language: en-US Accept-Language: en-US Thread-topic: [tcmtf] TCMTF: two kinds of services Thread-index: Ac2dWc3roSS93utvTYC2TKQuzRqQgwAEW7WA user-agent: Microsoft-MacOutlook/14.2.4.120824 X-AuditID: 0a5f4068-b7f176d000000bea-65-506587f3deb9 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLKsWRmVeSWpSXmKPExsXCFe/Apfu5PTXAYPlhTYtdnzcwOjB6LFny kymAMYrLJiU1J7MstUjfLoErY8FZj4JHdhU/1m1jb2DsMeti5OSQEDCRaH/TwQJhi0lcuLee rYuRi0NIYCOjxJ3lnSwQzk9GiV+vTzBDODMZJTbt3wLWwiKgKnFy8Xw2EJtNQEvi9N1VYHFh AUOJNVsaGUFsTgELia07XrJBrFCQ+HPuMViNiECAxO6WA2A2r4C3xOfNS9ggbEGJH5PvgcWZ BXIlbu7fzgphi0s0t94EizMCnfr91BomiDlGEk+Xf2GFsb+8mgU2R1RAT2LB7oPMEHsFJJbs OQ9li0q8fPyPdQKj6Cwk62YhWTcLyToIW0/ixtQpbBC2tsSyha+ZIWxdiRn/DkHVmElMP9/P jKxmASPHKkax4qSizPSMktzEzJx0A0O9jEy9zLzUkk2MkLjL2MG4fKfKIUYBDkYlHt4fCxMC hFgTy4orcw8xSnIwKYny3m1MDRDiS8pPqcxILM6ILyrNSS0+xCjBwawkwptRDJTjTUmsrEot yodJyXBwKEnwvm4DSgkWpaanVqRl5gCTC0yaiYMTpJ0HqJ2lHaS9uCAxtzgzHSJ/ilFSSpz3 B0izAEgiozQPrvcVozjQkcK8EiBtPMA0CNf1CmggE9DApZuSQAaWJCKkpBoYPQXWMz36WSXr 3rzNUHJFxT32p2Lc35oYeGeUf1z995KRlkXQZMcJ5SvXvAziuy0hcH3Fxlqv8zIuzVp/ty92 PvmU6cEP3vJ5gYuiOf782BVdMk/3ht5Vz1XJwuLtdR6RglO+z2Bff6bm6ZcPUpd2PT5knr37 jrKG9cSFTl4zcpWmp9+2bExXVWIpzkg01GIuKk4EAIzae9pAAwAA Subject: Re: [tcmtf] TCMTF: two kinds of services 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: Fri, 28 Sep 2012 11:20:23 -0000 --Boundary_(ID_VdLchu7ujyo1RXp4EZPRHw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi Jose, You are talking about dynamically apply TCMTF, and yes, this is a very inte= resting aspect. This is different from the third draft you proposed in orde= r to dynamically negotiate TCMTF parameters between multiplexer and demulti= plexer, that would be a higher entity in charge of decide when and where or= not to apply TCMTF, and what kind of TCMTF. As operator, we have a lot of = knowledge in those kind of policies. I have several colleagues that can tal= k about that issue. Regards, Fernando Pascual Blanco 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: viernes 28 de septiembre de 2012 11:17 To: "tcmtf@ietf.org" > Subject: [tcmtf] TCMTF: two kinds of services This is another thought to be discussed. We can have two different situatio= ns for multiplexing flows: - delay-sensitive services (e.g., VoIP, online games). In this case, TCMTF = would add some delay, so it should only be used when bandwidth is scarce (r= ush hours, new game release, etc.). If your network is working properly, wh= y do you need to save bandwidth and add a small delay to the clients? So in= rush hours there must be a counterpart in order to add some priority to th= e tunneled packets. Otherwise you would penalize them: since they are small= and can be multiplexed, they are delayed. - services sending small packets but not delay-sensitive (e.g., whatsapp, m= 2m packets being generated every second). In this case TCMTF saves bandwidt= h while adding some delay, but it is not critical. 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_VdLchu7ujyo1RXp4EZPRHw) Content-id: Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hi Jose,

You ar= e talking about dynamically apply TCMTF, and yes, this is a very interestin= g aspect. This is different from the third draft you proposed in order to d= ynamically negotiate TCMTF parameters between multiplexer and demultiplexer, that would be a higher entity in ch= arge of decide when and where or not to apply TCMTF, and what kind of TCMTF= . As operator, we have a lot of knowledge in those kind of policies. I have= several colleagues that can talk about that issue.

Regards,

Fernando Pascual Blanco

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: viernes 28 de septiembre de 2= 012 11:17
To: "tcmtf@ietf.org" <tcm= tf@ietf.org>
Subject: [tcmtf] TCMTF: two kinds o= f services

This is another thought to b= e discussed. We can have two different situations for multiplexing flows:

- delay-sensitive services (= e.g., VoIP, online games). In this case, TCMTF would add some delay, so it = should only be used when bandwidth is scarce (rush hours, new game release,= etc.). If your network is working properly, why do you need to save bandwidth and add a small delay to the clients? So= in rush hours there must be a counterpart in order to add some priority to= the tunneled packets. Otherwise you would penalize them: since they are sm= all and can be multiplexed, they are delayed.

- services sending small pac= kets but not delay-sensitive (e.g., whatsapp, m2m packets being generated e= very second). In this case TCMTF saves bandwidth while adding some delay, b= ut it is not critical.

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_VdLchu7ujyo1RXp4EZPRHw)-- From gorry@erg.abdn.ac.uk Fri Sep 28 05:07:02 2012 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 7BEB921F8620 for ; Fri, 28 Sep 2012 05:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdEmkdfYYTyJ for ; Fri, 28 Sep 2012 05:07:00 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4474B21F861E for ; Fri, 28 Sep 2012 05:07:00 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 253172B45FC; Fri, 28 Sep 2012 13:06:59 +0100 (BST) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id CF9442B44BF for ; Fri, 28 Sep 2012 13:06:55 +0100 (BST) Message-ID: <506592DF.7070508@erg.abdn.ac.uk> Date: Fri, 28 Sep 2012 13:06:55 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: tcmtf@ietf.org References: <003101cd9d62$c803f1f0$580bd5d0$@unizar.es> In-Reply-To: <003101cd9d62$c803f1f0$580bd5d0$@unizar.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [tcmtf] More satellite scenarios X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk 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, 28 Sep 2012 12:07:02 -0000 I did not dispute the use of VoIP and other "small packet" services over satellite (I work on this subject). What I wanted to understand was why ROHC or RFC 3545 (e.g. for VoIP) was not applicable. Gorry On 28/09/2012 11:19, Jose Saldana wrote: > We have to continue the discussion about satellite scenarios with sensor > networks: if possible, I would like to hear the opinion of people from DLR > about this. > > > However, I have found more satellite-related scenarios in which a number of > small-packet flows can be present: > > - A cruise: lots of people (3800 people in Queen Mary 2) connected through a > satellite link > > http://www.cruisemates.com/articles/onboard/connected.cfm#axzz27l0sEqu3 > http://en.wikipedia.org/wiki/RMS_Queen_Mary_2 > http://www.esa.int/esaTE/SEMMAWNFGLE_index_0.html > > > - A plane: similar to the ship, but less people and no satellite, but ground > antennas communicating with a special antenna on the plane (VoIP is > prohibited by now): > http://en.wikipedia.org/wiki/Gogo_Inflight_Internet > > > - Satellite access in low-populated regions (e.g. Alaska): Perhaps a number > of people, or a village, may share a connection through an antenna: > http://www.skycasters.com/satellite-internet-coverage/skycasters-coverage-Al > aska.html > > > What do you think? > > Best regards, > > Jose > >> -----Mensaje original----- >> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de >> Gorry Fairhurst >> Enviado el: viernes, 21 de septiembre de 2012 10:29 >> Para: jsaldana@unizar.es >> CC: tcmtf@ietf.org; 'FERNANDO PASCUAL BLANCO' >> Asunto: Re: [tcmtf] Discussing M2M scenario and savings - continuing the >> thread >> >> I think *IF* the satellite link is a DVB 2nd generation RF link, e.g. >> DVB-S2 for satellite ( a common waveform), then GSE + RFC 5163 is a >> reasonable proposal, on which one may benefit if one layers a HC scheme, >> such as ROHC, or 6LoWPAN. The profile for the ROHC schemes have not >> been specified for this type of link - but the relevant RFCs exist for the >> compression itself. RFC 3135 and RFC 3449 also describe TCP/IP techniques > to >> help improve efficiency on such links. >> >> As I said, I do not see the *benefit* for the mux and demux in the > scenario >> as drawn, since this seems more like *link* HC, and it would seem foolish > to >> form aggregate traffic over a single link layer in the way that tunnel >> compression implements this. >> >> If the drawing extended the network on one or both sides of the satellite >> link, there could be a reason for using tunnel HC, although I am not sure >> whether this is commercially important, since unlike an access network, > the >> connectivity to the hub (usually known as the satellite gateway) on the > left of >> the figure is not usually a low speed access link and the merits of HC is > less >> obvious where bandwidth is high. Also, it would seem desirable to use >> encapsulation and HC mechanisms on the satellite air interface anyway, RFC >> 3135 part 3 (from the source), possibly combined with RFC 3449 mechanisms. >> >> All I am saying is you have to be sure to describe the scenario carefully > and >> explain why HC applies in this case and what alternatives exist. >> >> Gorry >> >> On 20/09/2012 17:20, Jose Saldana wrote: >>> So, do you think the figure should be modified? Perhaps it is >>> currently confusing, since it seems that RFC 5163 is the best >>> solution. Perhaps a network should be included between the demux and >>> the data center? Or between the antenna and the demux? Will this be a >>> real case? I don't know if in the right side it is possible to find > other >> networks. >>> >>> I am talking about this figure: >>> >>> http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenario.pd >>> f >>> >>> Thanks, >>> >>> Jose >>> >>> -----Mensaje original----- >>> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre >>> de FERNANDO PASCUAL BLANCO Enviado el: mi�rcoles, 19 de septiembre >> de >>> 2012 13:02 >>> Para: gorry@erg.abdn.ac.uk; tcmtf@ietf.org >>> Asunto: Re: [tcmtf] Discussing M2M scenario and savings - continuing >>> the thread >>> >>> Hi Gorry, >>> >>> Absolutely. The tunneling layer would increase that benefit >>> in a multi-router hop path, being the satellite-link part of this path. >>> >>> Regards, >>> >>> Fernando Pascual Blanco >>> >>> Telef�nica Global Resources >>> >>> Network Automation and Dynamization >>> >>> TECHNOLOGY PEOPLE GROUP >>> >>> F +34913128779 >>> >>> M +34682005168 >>> >>> fpb@tid.es >>> >>> On 19/09/12 12:37, "gorry@erg.abdn.ac.uk >> " >>> > wrote: >>> >>> > >>> >>> >For a point-to-point link carrying traffic destined to a ingle L2 >>> >>> >address, I don't see how this helps above the gains of ROHC or some >>> >>> >other HC on the link, when possibly combining this with link layer >>> >>> >transmission options e.g. methods like PDU-CONCAT in RFC 5163. >>> >>> > >>> >>> >If you're working over a multi-router network hop, the >>> considerations >>> >>> >may be different. >>> >>> > >>> >>> >Gorry >>> >>> > >>> >>> >> Hi Gorry, >>> >>> >> >>> >>> >> I don´t know a lot about link layer HC, but I imagine that >>> >>> >> it compress packet headers (IP-TCP/UDP). If, in addition to that, >>> we >>> >>> >> group several small packets into a bigger one (using PPP-Mux and >>> >>> >> RoHC), don´t you think more resources could be saved? >>> >>> >> >>> >>> >> Regards, >>> >>> >> >>> >>> >> Fernando Pascual Blanco >>> >>> >> Telefónica Global Resources >>> >>> >> Network Automation and Dynamization >>> >>> >> TECHNOLOGY PEOPLE GROUP >>> >>> >> F +34913128779 >>> >>> >> M +34682005168 >>> >>> >> fpb@tid.es >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> On 19/09/12 10:56, "gorry@erg.abdn.ac.uk >>> " >> > wrote: >>> >>> >> >>> >>> >>>I know there are applications for tunnel compression - but I'm not >>> >>> >>>sure I understand how this can gain further than for link-layer HC? >>> >>> >>> >>> >>> >>>Gorry >>> >>> >>> >>> >>> >>>> Hi Gorry, >>> >>> >>>> >>> >>> >>>> In addition of HC (header compression), the multiplexing >>> >>> >>>> layer will save even more resources. In that case and assuming >>> that >>> >>> >>>> all the traffic through the link have the same QoS requirements >>> >>> >>>> (for example a sensor network), the idea would be to group all >>> the >>> >>> >>>> flows through the link (the bottleneck). >>> >>> >>>> >>> >>> >>>> Regards, >>> >>> >>>> >>> >>> >>>> Fernando Pascual Blanco >>> >>> >>>> Telefónica Global Resources >>> >>> >>>> Network Automation and Dynamization TECHNOLOGY PEOPLE >> GROUP F >>> >>> >>>> +34913128779 M +34682005168 fpb@tid.es >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> On 18/09/12 20:46, "Gorry Fairhurst" >> > wrote: >>> >>> >>>> >>> >>> >>>>>A satellite "link" may provide HC, at least some of the ones I >>> have >>> >>> >>>>>seen do. In this case, the flows can easily be grouped by mac >>> >>> >>>>>address? >>> >>> >>>>> >>> >>> >>>>>Gorry >>> >>> >>>>> >>> >>> >>>>>On 13/09/2012 16:20, Jose Saldana wrote: >>> >>> >>>>>> Hi, Fernando, sorry for the delay (one week, I¹m afraid). >>> >>> >>>>>> >>> >>> >>>>>> I don¹t know who is the one interested on using TCMTF: >>> >>> >>>>>> >>> >>> >>>>>> -If you are a costumer, and you have to pay for a satellite >>> link >>> >>> >>>>>>or a long distance wire, perhaps you are the one interested >>> on >>> >>> >>>>>>using end-to-end TCMTF, since you will save bandwidth or >>> packets >>> >>> >>>>>>per second or money. If you have e.g. two offices, one in >>> >>> >>>>>>America and other one in Europe, you may be interested on >>> placing >>> >>> >>>>>>a device for multiplexing a number of VoIP calls between them. >>> >>> >>>>>>You have one advantage: the flows have the same origin and >>> >>> >>>>>>destination, so header compression is effective. >>> >>> >>>>>> >>> >>> >>>>>> -If you are the operator of the satellite, you have another >> problem: >>> >>> >>>>>> you >>> >>> >>>>>> may have to check every flow, and try to group them. Perhaps >>> it >>> >>> >>>>>> may be easy, but if you want to save headers, you need flows >>> with >>> >>> >>>>>> the same origin and destination. >>> >>> >>>>>> >>> >>> >>>>>> I think that there are different scenarios, and each ³actor² >>> >>> >>>>>>may try to use TCMTF in the best place: a high number of >>> flows, >>> >>> >>>>>>with small packets, and sharing the same origin and > destination. >>> >>> >>>>>> >>> >>> >>>>>> Do you agree? >>> >>> >>>>>> >>> >>> >>>>>> Jose >>> >>> >>>>>> >>> >>> >>>>>> *De:*tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] >>> *En >>> >>> >>>>>> nombre de *FERNANDO PASCUAL BLANCO *Enviado el:* martes, >> 04 de >>> >>> >>>>>> septiembre de 2012 12:27 >>> >>> >>>>>> *Para:* tcmtf@ietf.org >>> >>> >>>>>> *Asunto:* Re: [tcmtf] Discussing M2M scenario and savings >>> >>> >>>>>> >>> >>> >>>>>> Hi all, >>> >>> >>>>>> >>> >>> >>>>>> Yes, M2M sensor networks are a very good example in order to >>> save >>> >>> >>>>>> bandwidth in long distance/big latency/low bandwidth links, >>> links >>> >>> >>>>>> were the cost per bit is high. Do you think network carriers >>> >>> >>>>>> operating this kind of links (satellite links or long distance >>> >>> >>>>>> wires) would be interested in apply TCMTF? >>> >>> >>>>>> >>> >>> >>>>>> Regards, >>> >>> >>>>>> >>> >>> >>>>>> Fernando >>> >>> >>>>>> >>> >>> >>>>>> *From:*tcmtf-bounces@ietf.org > bounces@ietf.org> >>> >>> >>>>>> [mailto:tcmtf-bounces@ietf.org] >>> >>> >>> >>>>>> >>> >>> >>>>>> *On Behalf Of *Jose Saldana >>> >>> >>>>>> *Sent:* martes, 04 de septiembre de 2012 9:41 >>> >>> >>>>>> *To:* tcmtf@ietf.org >>> >>> >>> >>>>>> *Cc:* Matteo.Berioli@dlr.de >>> ; >>> >>> >>>>>> Tomaso.deCola@dlr.de >>> >>> >>> >>>>>> *Subject:* [tcmtf] Discussing M2M scenario and savings >>> >>> >>>>>> >>> >>> >>>>>> Hi again, >>> >>> >>>>>> >>> >>> >>>>>> We already discussed some points about the M2M scenario at the >>> >>> >>>>>>beginning of August. We are currently studying this, and we >>> have >>> >>> >>>>>>built some figures, in collaboration with people from DLR >>> (Tomaso >>> >>> >>>>>>and Matteo). >>> >>> >>>>>>You >>> >>> >>>>>> can find the figures here: >>> >>> >>>>>> >>> >>> >>>>>> >>> >>> >>> >>>>>>>> http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_savin >>> gs >>> >>> >>>>>>.pd >>> >>> >>>>>>f >>> >>> >>>>>> >>> >>> >>>>>> >>> >>> >>> >>>>>>>> http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scena >>> ri >>> >>> >>>>>>o.p >>> >>> >>>>>>df >>> >>> >>>>>> >>> >>> >>>>>> Perhaps we could comment them, in order to discuss this >>> scenario, >>> >>> >>>>>> and we may find new ones in which TCMTF can be useful. >>> >>> >>>>>> >>> >>> >>>>>> Thanks, >>> >>> >>>>>> >>> >>> >>>>>> Jose >>> >>> >>>>>> >>> >>> >>>>>> >>> >>> >>>>>>>>> ---------------------------------------------------------------- >>> -- >>> >>> >>>>>>--- >>> >>> >>>>>>-- >>> >>> >>>>>>- >>> >>> >>>>>> >>> >>> >>>>>> >>> >>> >>>>>> Este mensaje se dirige exclusivamente a su destinatario. Puede >>> >>> >>>>>> consultar nuestra política de envío y recepción de correo >>> >>> >>>>>> electrónico en el enlace situado más 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 >>> >>> >>>>>> >>> >>> >>>>>> >>> >>> >>>>>> >>> >>> >>>>>> _______________________________________________ >>> >>> >>>>>> tcmtf mailing list >>> >>> >>>>>> tcmtf@ietf.org >>> >>> >>>>>> https://www.ietf.org/mailman/listinfo/tcmtf >>> >>> >>>>>> >>> >>> >>>>> >>> >>> >>>>>_______________________________________________ >>> >>> >>>>>tcmtf mailing list >>> >>> >>>>>tcmtf@ietf.org >>> >>> >>>>>https://www.ietf.org/mailman/listinfo/tcmtf >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> ________________________________ >>> >>> >>>> >>> >>> >>>> Este mensaje se dirige exclusivamente a su destinatario. Puede >>> >>> >>>> consultar nuestra política de envío y recepción de correo >>> >>> >>>> electrónico en el enlace situado más 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 >>> >>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> >> >>> >>> >> >>> >>> >> ________________________________ >>> >>> >> >>> >>> >> Este mensaje se dirige exclusivamente a su destinatario. Puede >>> >>> >> consultar nuestra política de envío y recepción de correo >>> >>> >> electrónico en el enlace situado más 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 >>> >>> >> >>> >>> > >>> >>> > >>> >>> > >>> >>> >_______________________________________________ >>> >>> >tcmtf mailing list >>> >>> >tcmtf@ietf.org >>> >>> >https://www.ietf.org/mailman/listinfo/tcmtf >>> >>> ________________________________ >>> >>> Este mensaje se dirige exclusivamente a su destinatario. Puede >>> consultar nuestra pol�tica de env�o y recepci�n de correo electr�nico >>> en el enlace situado m�s 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 >>> >>> _______________________________________________ >>> >>> tcmtf mailing list >>> >>> tcmtf@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/tcmtf >>> >>> >>> >>> _______________________________________________ >>> tcmtf mailing list >>> tcmtf@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcmtf >>> >> >> _______________________________________________ >> tcmtf mailing list >> tcmtf@ietf.org >> https://www.ietf.org/mailman/listinfo/tcmtf > > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf > From sophie.nachmanghnassia@orange.com Fri Sep 28 06:02:53 2012 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 D7CCE21F846B for ; Fri, 28 Sep 2012 06:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+jGT3JOlDrk for ; Fri, 28 Sep 2012 06:02:53 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id BDDCE21F851C for ; Fri, 28 Sep 2012 06:02:52 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 7A8D0324053; Fri, 28 Sep 2012 15:02:51 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 5CF3B238048; Fri, 28 Sep 2012 15:02:51 +0200 (CEST) Received: from PUEXCB2C.nanterre.francetelecom.fr ([10.64.14.42]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 28 Sep 2012 15:02:51 +0200 From: To: "jsaldana@unizar.es" Date: Fri, 28 Sep 2012 15:02:47 +0200 Thread-Topic: [tcmtf] Next steps with TCMTF Thread-Index: Ac2c4mOXdKbkPrwdR02shQPkoRSSNQAlve2Q Message-ID: <6342_1348837371_50659FFB_6342_360_1_926908559A503C4BBF65A28DB676B861C43D132DA6@PUEXCB2C.nanterre.francetelecom.fr> References: <506471C4.2060903@ericsson.com> <001201cd9cc8$27769ed0$7663dc70$@unizar.es> In-Reply-To: <001201cd9cc8$27769ed0$7663dc70$@unizar.es> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: "tcmtf@ietf.org" Subject: Re: [tcmtf] Next steps with TCMTF 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: Fri, 28 Sep 2012 13:02:54 -0000 Hello,=20 I agree on this approach: to launch a WG. Thank you. BR=20 Sophie Nachman-Ghnassia France Telecom Orange -----Message d'origine----- De=A0: Jose Saldana [mailto:jsaldana@unizar.es]=20 Envoy=E9=A0: jeudi 27 septembre 2012 17:53 =C0=A0: 'Gonzalo Camarillo' Cc=A0: tcmtf@ietf.org Objet=A0: Re: [tcmtf] Next steps with TCMTF Thanks, Gonzalo. As you suggest, a good approach could be hearing and discussing people's opinions about the work to be deployed, and build a charter with that. I think that next week I could build a first version of the charter, and then we could polish it on the list. Thank you, Jose > -----Mensaje original----- > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de > Gonzalo Camarillo > Enviado el: jueves, 27 de septiembre de 2012 17:33 > Para: FERNANDO PASCUAL BLANCO > CC: tcmtf@ietf.org; Wesley Eddy; Martin Stiemerling; jsaldana@unizar.es > Asunto: Re: [tcmtf] Next steps with TCMTF >=20 > Hi Jose Maria, >=20 > if the idea is to create a WG to work on these drafts, what you need to do is > to propose a draft charter, polish it on this list, and then present it to Wes > and Martin at some point so that they can create the WG. >=20 > You have many examples of charters on the IETF WG pages, of course. >=20 > Cheers, >=20 > Gonzalo >=20 > On 27/09/2012 6:08 PM, FERNANDO PASCUAL BLANCO wrote: > > Hi Jose, > > > > I absolutely agree with your classification. Nevertheless I > > miss a draft explaining how to deal with different QoS flows passing > > through a TCMTF > > tunnel: Should we map packet marks like DiffServ to different tunnels > > between the same points? Could we mix some flows and under what > > conditions? Do you think that would be included in your second draft > > proposal? > > > > Regards, > > > > Fernando Pascual Blanco > > Telef=F3nica Global Resources > > Network Automation and Dynamization > > TECHNOLOGY PEOPLE GROUP > > F +34913128779 > > M +34682005168 > > fpb@tid.es > > > > > > > > > > On 27/09/12 12:31, "Jose Saldana" wrote: > > > >> Hello all, > >> > >> I would like to discuss in this list the possibility of creating a > >> small Working Group for TCMTF, as suggested by Wes. It could have the > >> task of making a RFC from TCMTF, or a wider scope. I think that > >> perhaps more than a draft would be necessary. I mean, I have been > >> thinking about it, and perhaps the work could be divided into the > >> next parts: > >> > >> a) "Current draft": the main draft (draft-saldana-tsvwg-tcmtf-03), > >> including the protocol stack of TCMTF. The current proposal has > >> different options, but the concrete one to use is static: in the > >> set-up moment, you decide that "between these two routers a tunnel is > >> set including all the packets with this IP origin and destination". > >> > >> b) "Recommendations draft": another "informational" one, with > >> recommendations of maximum delays to be added to different kinds of > >> services, different multiplexing policies, implementation issues > >> related to the selection of the best compression algorithm to use, > >> etc. Some hypothetical examples: > >> - "if you are multiplexing a First Person Shooter, your > >> multiplexer should not retain packets more than 50 ms" > >> - "if you are multiplexing in a low-end router in a wired scenario, > >> you don't need to use ROHC. A simpler scheme like IPHC can be enough, > >> and it will not require a lot of processing capacity". > >> > >> c) "Dynamic Signaling draft": perhaps another one including a > >> signaling system in order to: > >> - dynamically "negotiate" the concrete options of TCMTF you are > >> going to use > >> - if two routers notice that a rush hour is arriving, they > >> could send some packets asking other routers if they have some flows > >> in common with them, which could be multiplexed. > >> > >> > >> The main questions are: > >> > >> Is this enough for creating a working group? > >> > >> Do you think the distribution of the work into three draft makes sense? > >> > >> Is there any other issue which should be studied and standardized? > >> Perhaps other people could imagine more things. > >> > >> So let's start the discussion. > >> > >> Thanks in advance, > >> > >> Jose > >> > >> > >> _______________________________________________ > >> tcmtf mailing list > >> tcmtf@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcmtf > > > > > > ________________________________ > > > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el= enlace > situado m=E1s abajo. > > This message is intended exclusively for its addressee. We only send and > receive email on the basis of the terms set out at: > > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > > _______________________________________________ > > tcmtf mailing list > > tcmtf@ietf.org > > https://www.ietf.org/mailman/listinfo/tcmtf > > >=20 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From touch@isi.edu Fri Sep 28 11:15:50 2012 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 1416421F84F2 for ; Fri, 28 Sep 2012 11:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mTsJ-PIzeJ2 for ; Fri, 28 Sep 2012 11:15:49 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8959721F848F for ; Fri, 28 Sep 2012 11:15:49 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q8SIFFQg000189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Sep 2012 11:15:15 -0700 (PDT) Message-ID: <5065E933.3080709@isi.edu> Date: Fri, 28 Sep 2012 11:15:15 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: jsaldana@unizar.es References: <001d01cd9d5d$239aa870$6acff950$@unizar.es> In-Reply-To: <001d01cd9d5d$239aa870$6acff950$@unizar.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcmtf@ietf.org Subject: Re: [tcmtf] TCMTF: The importance of the layers 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: Fri, 28 Sep 2012 18:15:50 -0000 On 9/28/2012 2:39 AM, Jose Saldana wrote: > (this message has to be seen in Courier letters) > ... > What do you think? Are these things implicit in the method, or should we > also include them in the draft(s)? I think IETF WGs are bad places to *design* protocols. A comparison of the different approaches you give would be useful, especially if based on an implementation, but that suggests further research is needed before proceeding. Joe From Mirko.Suznjevic@fer.hr Sat Sep 29 04:10:23 2012 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 6FFE121F8550 for ; Sat, 29 Sep 2012 04:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta193uETyX5Z for ; Sat, 29 Sep 2012 04:10:22 -0700 (PDT) Received: from mail.zvne.fer.hr (mail.zvne.fer.hr [161.53.66.5]) by ietfa.amsl.com (Postfix) with ESMTP id EDAE521F854F for ; Sat, 29 Sep 2012 04:10:21 -0700 (PDT) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.2.298.4; Sat, 29 Sep 2012 13:10:19 +0200 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Sat, 29 Sep 2012 13:10:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD9E33.0280E88E" Date: Sat, 29 Sep 2012 13:10:18 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcmtf] Next steps with TCMTF Thread-Index: Ac2cmrry4BaRIpi1Sm27mcZI4g4aKwBlpMWE References: <007801cd9c9b$3b06d5a0$b11480e0$@unizar.es> From: =?iso-8859-2?Q?Mirko_Su=BEnjevi=E6?= To: X-OriginalArrivalTime: 29 Sep 2012 11:10:18.0824 (UTC) FILETIME=[02A10480:01CD9E33] Subject: Re: [tcmtf] Next steps with TCMTF 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: Sat, 29 Sep 2012 11:10:23 -0000 ------_=_NextPart_001_01CD9E33.0280E88E Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Regarding the "Recommendations draft", we are currently in a process of = applying a general purpose Quality of Experience model for one type of = games (MMORPGs). We will for sure investigate the influence of delay (among other things) = on MMORPGs and can also provide some information regarding other game = types.=20 We in Zagreb are studying these problems, so we may also participate on = the draft or collaborate in this area in general.=20 There has been quite a number of papers describing the delay influence = on performance in First Person Shooters (FPS), and also other game = types. So as our group has some expertise in this area we can provide you with = some numbers, as well as to provide QoE data which supports the numbers. If i may suggest a table comprising different game types and limits on = which significant QoE (or QoS) degradation starts to occur. Would that be appropriate? Cheers! Mirko Suznjevic -----Original Message----- From: tcmtf-bounces@ietf.org on behalf of Jose Saldana Sent: =E8et 27.9.2012 12:31 To: tcmtf@ietf.org Cc: Wesley Eddy; Martin Stiemerling Subject: [tcmtf] Next steps with TCMTF =20 Hello all, I would like to discuss in this list the possibility of creating a small Working Group for TCMTF, as suggested by Wes. It could have the task of making a RFC from TCMTF, or a wider scope. I think that perhaps more = than a draft would be necessary. I mean, I have been thinking about it, and = perhaps the work could be divided into the next parts: a) "Current draft": the main draft (draft-saldana-tsvwg-tcmtf-03), including the protocol stack of TCMTF. The current proposal has = different options, but the concrete one to use is static: in the set-up moment, = you decide that "between these two routers a tunnel is set including all the packets with this IP origin and destination". =20 b) "Recommendations draft": another "informational" one, with recommendations of maximum delays to be added to different kinds of services, different multiplexing policies, implementation issues related = to the selection of the best compression algorithm to use, etc. Some hypothetical examples: - "if you are multiplexing a First Person Shooter, your = multiplexer should not retain packets more than 50 ms" - "if you are multiplexing in a low-end router in a wired scenario, you don't need to use ROHC. A simpler scheme like IPHC can be enough, and it will not require a lot of processing capacity". =20 c) "Dynamic Signaling draft": perhaps another one including a signaling system in order to: - dynamically "negotiate" the concrete options of TCMTF you are going to use - if two routers notice that a rush hour is arriving, they could send some packets asking other routers if they have some flows in common with them, which could be multiplexed. =20 The main questions are: Is this enough for creating a working group? Do you think the distribution of the work into three draft makes sense? Is there any other issue which should be studied and standardized? = Perhaps other people could imagine more things. So let's start the discussion. Thanks in advance, Jose=20 _______________________________________________ tcmtf mailing list tcmtf@ietf.org https://www.ietf.org/mailman/listinfo/tcmtf ------_=_NextPart_001_01CD9E33.0280E88E Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable RE: [tcmtf] Next steps with TCMTF
Regarding the "Recommendations draft", we = are currently in a process of applying a general purpose Quality of = Experience model for one type of games (MMORPGs).
We will for sure investigate the influence of delay (among other things) = on MMORPGs and can also provide some information regarding other game = types.
We in Zagreb are studying these problems, so we may also participate on = the draft or collaborate in this area in general.

There has been quite a number of papers describing the delay influence = on performance in First Person Shooters (FPS), and also other game = types.
So as our group has some expertise in this area we can provide you with = some numbers, as well as to provide QoE data which supports the = numbers.

If i may suggest a table comprising different game types and limits on = which significant QoE (or QoS) degradation starts to occur.
Would that be appropriate?

Cheers!
Mirko Suznjevic

-----Original Message-----
From: tcmtf-bounces@ietf.org on behalf of Jose Saldana
Sent: =E8et 27.9.2012 12:31
To: tcmtf@ietf.org
Cc: Wesley Eddy; Martin Stiemerling
Subject: [tcmtf] Next steps with TCMTF

Hello all,

I would like to discuss in this list the possibility of creating a = small
Working Group for TCMTF, as suggested by Wes. It could have the task = of
making a RFC from TCMTF, or a wider scope. I think that perhaps more = than a
draft would be necessary. I mean, I have been thinking about it, and = perhaps
the work could be divided into the next parts:

a) "Current draft": the main draft = (draft-saldana-tsvwg-tcmtf-03),
including the protocol stack of TCMTF. The current proposal has = different
options, but the concrete one to use is static: in the set-up moment, = you
decide that "between these two routers a tunnel is set including = all the
packets with this IP origin and destination".

b) "Recommendations draft": another "informational" = one, with
recommendations of maximum delays to be added to different kinds of
services, different multiplexing policies, implementation issues related = to
the selection of the best compression algorithm to use, etc. Some
hypothetical examples:
      - "if you are multiplexing a = First Person Shooter, your multiplexer
should not retain packets more than 50 ms"
- "if you are multiplexing in a low-end router in a wired scenario, = you
don't need to use ROHC. A simpler scheme like IPHC can be enough, and = it
will not require a lot of processing capacity".

c) "Dynamic Signaling draft": perhaps another one including a = signaling
system in order to:
        - dynamically = "negotiate" the concrete options of TCMTF you are
going to use
        - if two routers notice that = a rush hour is arriving, they could
send some packets asking other routers if they have some flows in = common
with them, which could be multiplexed.

The main questions are:

Is this enough for creating a working group?

Do you think the distribution of the work into three draft makes = sense?

Is there any other issue which should be studied and standardized? = Perhaps
other people could imagine more things.

So let's start the discussion.

Thanks in advance,

Jose

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

------_=_NextPart_001_01CD9E33.0280E88E--