Well, Stephen… we are still in an early stage of tcm-tf. Today = we have had a session in the IETF with the aim of starting the = standardization process, but we would need some = time.

If everything goes well, in our research group in University of = Zaragoza, we have some plans for building an open-source implementation = that could be useful for the first stages of = standardization.

If you want, I can keep you informed. Our idea is to reuse some = already available implementations of some of the protocols. For example, = an implementation of ROHC is being developed here: http://sourceforge.net/pro= jects/rohc/

Of course, if you would like to do an implementation or to = collaborate in ours, it would be fine.

By the way, I have seen your video about “meshpotato” and = it seems really smart.

Best regards and nice to hear from you!

Jose

De: = tcmtf [mailto:tcmtf-bounces@ietf.org] En nombre de Song, = Stephen
Enviado el: martes, 04 de marzo de 2014 = 17:53
Para: tcmtf@ietf.org
Asunto: [tcmtf] interest = in tcm-tf

Hi,

I = am the founder of Village Telco Ltd (http://villagetelco.org). We = deliver voice and data over wireless mesh networks. Is there an = implementable version of tcm-tf available on any platform? We = would be very interested in trialing it.

Thanks... Steve

-- =
Steve Song

+1 902 529 = 0046

http://manypossibilities.net
http://villagetelco.org

<= /div>

------=_NextPart_000_006A_01CF37EE.E7D58CF0-- From nobody Wed Mar 5 05:09:00 2014 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2291A02AD for ; Wed, 5 Mar 2014 05:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooHkq2_xi7C0 for ; Wed, 5 Mar 2014 05:08:55 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 29E4A1A006B for ; Wed, 5 Mar 2014 05:08:55 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id i8so1045577qcq.3 for ; Wed, 05 Mar 2014 05:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3J23PodVagTF2H5IzLZqo2HiOeVw4BHRrvt5t4bL630=; b=QnshCu6Z3FT6teDzN0lmQiRFbI5u7sdVadhDO6vn7V0PmoFvowomZHptmEdCViNA8n 91trPJSf9zvD6zLoKqVfGJC6nhBMVcUASbEMEBKtvIqph5n9joHGQw8opGbrBqPMxXMR +T4XzpHIWjFUCnyxxdYo8/Fil+VNJz461ygC2EWTuHh6qL6+Okh5TIYSz7rMbHym9Q1a wLX6nnaUXRxJ9/T0z1w7P49soWS0DURVFzDNEsUk2nEFG6AahsleHnkDVdc4TThqDzTF BmpylsV9D63atIUMVu0eC0bL9iblc8EeOnAl5qzMTdyOCRiZFoWvI8D+lr+xCqDO7b3P a2zw== MIME-Version: 1.0 X-Received: by 10.224.136.195 with SMTP id s3mr1991635qat.95.1394024931461; Wed, 05 Mar 2014 05:08:51 -0800 (PST) Received: by 10.96.101.67 with HTTP; Wed, 5 Mar 2014 05:08:51 -0800 (PST) Date: Wed, 5 Mar 2014 13:08:51 +0000 Message-ID: From: Alexander Harrowell To: tcmtf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcmtf/0LvnwdEvg3WFswdiGRRYqdVUhJc Subject: [tcmtf] Scenarios or Use Cases? X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.15 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, 05 Mar 2014 13:08:58 -0000 There was some discussion of this at the BOF in IETF 89. Re-reading, there are in fact use cases embedded in the scenarios, but as it stands I think the section mixes the use cases that motivate users with the description of where in a network it might be deployed. Here's the relevant section of the I-D: 1.4.1. Multidomain scenario In this scenario, the TCMT-TF tunnel goes all the way from one network edge (the place where users are attached to the ISP) to another, and therefore it can cross several domains. As shown in Figure 1, the optimization is performed before the packets leave the domain of an ISP; the traffic crosses the Internet tunnelized, and the packets are rebuilt in the second domain. _ _ _ _ _ _ ( ' ) _ _ _ ( ' )_ _ ( +------+ )') ( ' )_ ( +------+ ') -->(_ -|TCM-IO|--- _) ---> ( ) ') ----->(_-|TCM-EO|--_)--> ( +------+ _) (_ (_ . _) _) ( +------+ _) (_ _ _ _) (_ _ ( _) _) ISP 1 Internet ISP 2 <------------------TCM-TF--------------------> Figure 1 Note that this is not from border to border (where ISPs connect to the Internet, which could be covered with specialized links) but from an ISP to another (e.g. managing all traffic from individual users arriving at a Game Provider, regardless users' location). Some examples of this could be: o An ISP could place a TCM optimizer in its aggregation network, in order to tunnel all the packets of a service, sending them to the application provider, who would rebuild the packets before forwarding them to the application server. This would result in savings for both actors. o A service provider (e.g., an online gaming company) could be allowed to place a TCM optimizer in the aggregation network of an ISP, being able to optimize all the flows of a game or service. Another TCM optimizer would rebuild these packets once they arrive to the network of the provider. 1.4.2. Single domain TCM-TF is only activated inside an ISP, from the edge to border, inside the network operator. The geographical scope and network depth of TCM-TF activation could be on demand, according to traffic conditions. If we consider the residential users of a real-time interactive application (e.g., VoIP, an online game generating small packets) in a town or a district, a TCM optimizing module can be included in network devices, in order to group packets with the same destination. As shown in Figure 2, depending on the number of users of the application, the packets could be grouped at different levels in DSL fixed network scenarios, at gateway level in LTE mobile network scenarios or even in other ISP edge routers. TCM-TF may also be applied for fiber residential accesses, and in 2G/3G mobile networks. This would reduce bandwidth requirements in the provider aggregation network +------+ N users -|TCM-IO|\ +------+ \ \ _ _ _ _ +------+ \--> ( ' )_ +------+ ( ' )_ M users -|TCM-IO|------> ( ) ') --|TCM-EO|--> ( ) ') +------+ / ->(_ (_ . _) _) +------+ (_ (_ . _) _) / +------+ / ISP Internet P users -|TCM-IO|/ +------+ <------------TCM-TF--------------> Figure 2 At the same time, the ISP would implement TCM-TF capabilities within its own MPLS network in order to optimize internal network resources: optimizing modules could be embedded in the Label Edge Routers of the network. In that scenario MPLS would be the "tunneling" layer, being the tunnels the paths defined by the MPLS labels and avoiding the use of other tunneling protocols. Finally, some networks use cRTP [cRTP] in order to obtain bandwidth savings on the access link, but as a counterpart it consumes considerable CPU resources on the aggregation router. In these cases, by means of TCM, instead of only saving bandwidth on the access link, it could also be saved across the ISP network, without the CPU impact on the aggregation router. 1.4.3. Private solutions End users can also optimize traffic end-to-end from network borders. TCM-TF is used to connect private networks geographically apart (e.g. corporation headquarters and subsidiaries), without the ISP being aware (or having to manage) those flows, as shown in Figure 3, where two different locations are connected through a tunnel traversing the Internet or another network. _ _ _ _ _ _ ( ' )_ +------+ ( ' )_ +------+ ( ' )_ ( ) ') --|TCM-IO|-->( ) ') --|TCM-EO|-->( ) ') (_ (_ . _) _) +------+ (_ (_ . _) _) +------+ (_ (_ . _)_) Location 1 ISP/Internet Location 2 <-----------TCM-TF----------> Figure 3 Some examples of these scenarios: o The case of an enterprise with a number of distributed central offices, in which an appliance could be placed next to the access router, being able to optimize traffic flows with a shared origin and destination. Thus, a number of remote desktop sessions to the same server could be optimized, or a number of VoIP calls between two offices could also require less bandwidth and fewer packets per second. In some cases the tunnel is already included for security reasons, so the additional overhead of TCM-TF is lower. o An Internet cafe, which is suitable of having many users of the same application (e.g., VoIP, a game) sharing the same access link. Internet cafes are very popular in countries with relatively low access speeds in households, where home computer penetration is usually low as well. In many of these countries, bandwidth can become a serious limitation for this kind of business, so TCM-TF savings may become interesting for their viability. o Community networks [topology_CNs] (typically deployed in rural areas or in developing countries), in which a number of people in the same geographical place share their connections in a cooperative way, and a number of wireless hops are required in order to reach a router connected to the Internet. o Satellite communication links that often manage the bandwidth by limiting the transmission rate, measured in packets per second (pps), to and from the satellite. Applications like VoIP that generate a large number of small packets can easily fill the maximum number of pps slots, limiting the throughput across such links. As an example, a G.729a voice call generates 50 pps at 20 ms packetization time. If the satellite transmission allows 1,500 pps, the number of simultaneous voice calls is limited to 30. This results in poor utilization of the satellite link's bandwidth as well as places a low bound on the number of voice calls that can utilize the link simultaneously. TCM optimization of small packets into one packet for transmission would improve the efficiency. o In a M2M/SCADA (Supervisory Control And Data Acquisition) context, TCM optimization can be applied when a satellite link is used for collecting the data of a number of sensors. M2M terminals are normally equipped with sensing devices which can interface to proximity sensor networks through wireless connections. The terminal can send the collected sensing data using a satellite link connecting to a satellite gateway, which in turn will forward the M2M/SCADA data to the to the processing and control center through Internet. The size of typical M2M application transaction depends on the specific service and it may vary from a minimum of 20 bytes (e.g., tracking and metering in private security) to about 1,000 bytes (e.g., video-surveillance). In this context, TCM-TF concepts can be also applied to allow a more efficient use of the available satellite link capacity, matching the requirements demanded by some M2M services. If the case of large sensor deployments is considered, where proximity sensor networks transmit data through different satellite terminals, the use of compression algorithms already available in current satellite systems to reduce the overhead introduced by UDP and IPv6 protocols is certainly desirable. In addition to this, tunneling and multiplexing functions available from TCM-TF allows extending compression functionality throughout the rest the network, to eventually reach the processing and control centers. o Desktop or application sharing where the traffic from the server to the client typically consists of the delta of screen updates. Also, the standard for remote desktop sharing emerging for WebRTC in the RTCWEB Working Group is: {something}/SCTP/UDP (Stream Control Transmission Protocol [SCTP]). In this scenario, SCTP/UDP could be used in other cases: chatting, file sharing and applications related to WebRTC peers. There could be hundreds of clients at a site talking to a server located at a datacenter over a WAN. Compressing, multiplexing and tunneling this traffic could save WAN bandwidth and potentially improve latency. 1.4.4. Mixed scenarios Different combinations of the previous scenarios can be considered. Agreements between different companies can be established in order to save bandwidth and to reduce packets per second. As an example, Figure 4 shows a game provider that wants to TCM-optimize its connections by establishing associations between different TCM-IO/EOs placed in the game server and several TCM-IO/EOs placed in the networks of different ISPs (agreements between the game provider and each ISP would be necessary). In every ISP, the TCM-IO/EO would be placed in the most adequate point (actually several TCM-IO/EOs could exist per ISP) in order to aggregate enough number of users. _ _ N users ( ' )_ +---+ ( ) ') |TCM|->(_ (_ . _) +---+ ISP 1 \ _ _ \ _ _ _ _ _ M users ( ' )_ \ ( ' ) ( ' ) ( ' ) +---+ ( ) ') \ ( ) ') ( ) ') +---+ ( ) ') |TCM|->(_ (_ ._)---- (_ (_ . _) ->(_ (_ . _)->|TCM|->(_ (_ . _) +---+ ISP 2 / Internet ISP 4 +---+ Game Provider _ _ / ^ O users ( ' )_ / | +---+ ( ) ') / +---+ |TCM|->(_ (_ ._) P users->|TCM| +---+ ISP 3 +---+ Figure 4 From nobody Wed Mar 5 05:51:55 2014 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2781A014E for ; Wed, 5 Mar 2014 05:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNCXyKP9gFIa for ; Wed, 5 Mar 2014 05:51:50 -0800 (PST) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 202561A01C0 for ; Wed, 5 Mar 2014 05:51:48 -0800 (PST) Received: from eduroam-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:152:7404:eb40:154a:3635]) by trammell.ch (Postfix) with ESMTPSA id E24BD1A00D0 for ; Wed, 5 Mar 2014 14:51:13 +0100 (CET) From: Brian Trammell Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Mar 2014 13:51:11 +0000 References: <6FE75E93-FF8E-4435-B2D6-6A44668D5AA7@tik.ee.ethz.ch> To: tcmtf@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.1 $1827$) X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/tcmtf/ZgO1vuCSg91ooUcnqKKaxfTf_no Subject: [tcmtf] Thank you for a great BoF! X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.15 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, 05 Mar 2014 13:51:52 -0000 Greetings, all, Thanks to everyone for yesterday's BoF. We got lots of good input, and a = better handle on what a future TCMTF WG might look like. There are a few issues we identified that we'll have to take into = consideration for a new draft of the charter: (1) make it clear that backward compatibility with RFC 4170 is a goal. (2) an applicability statement, which explains applications that benefit = from=20 TCMTF and the situations for which it is likely useful, and = applications=20 and situations for which it is not. This should address interactions = between=20 TCMTF tunnels and TCP cross traffic sharing a bottleneck link. (3) interactions with how this interacts with diverse lower layers, = especially with respect to different delay tolerances, will have to be = considered. And we'd really more input from vendors already building boxes in this = space, and operators deploying them, as input to scoping and = applicability. Best regards, Mirja and Brian (second TCMTF BoF chairs)= From nobody Wed Mar 5 08:21:38 2014 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051621A01ED for ; Wed, 5 Mar 2014 08:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LE03JBCjM_GT for ; Wed, 5 Mar 2014 08:21:31 -0800 (PST) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9895D1A01BF for ; Wed, 5 Mar 2014 08:21:30 -0800 (PST) Received: from jsaldanapc (dhcp-a32b.meeting.ietf.org [31.133.163.43]) (authenticated bits=0) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s25GLNZt011610; Wed, 5 Mar 2014 17:21:24 +0100 From: "Jose Saldana" To: "'Brian Trammell'" , Date: Wed, 5 Mar 2014 16:21:25 -0000 Message-ID: <011b01cf388e$f5155080$df3ff180$@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: Ac84jLntXgvsinnZTxGcjVHdIZypUw== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/tcmtf/o7Gan8wY2z8vaqWOKnKJXim9caw Subject: Re: [tcmtf] Backwards compatibility with RFC4170 X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.15 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, 05 Mar 2014 16:21:33 -0000 Hi, Brian, thanks for the summary of the BoF: It is clear that RFC4170 is one of the options of the tcmtf stack. If = people think we should maintain backwards compatibility instead of obsoleting = it, we should modify three sentences of the draft: (http://www.ietf.org/mail-archive/web/tcmtf/current/msg00493.html)=20 The current charter draft (v11) says: "3. So there is a need of replacing RFC4170 with an extended solution = able to optimize these new flows ..." "5. (...) In addition, since the current RFC 4170 would be considered as = one of the options, this RFC would be obsoleted." "Goals and Milestones =09 Specification of TCM-TF reference model and the scenarios of interest. = This would obsolete RFC4170." The new version could say instead: "3. So there is a need of adding new options to the one considered in RFC4170, thus building an extended solution able to optimize these new flows..." "5. (...) In addition, backwards compatibility with RFC 4170 will be granted, since it will be considered as one of the optimization = options." "Goals and Milestones =09 Specification of TCM-TF reference model and the scenarios of interest. Backwards compatibility with RFC4170 will be granted." What do you think? Jose > -----Mensaje original----- > De: tcmtf [mailto:tcmtf-bounces@ietf.org] En nombre de Brian Trammell > Enviado el: mi=E9rcoles, 05 de marzo de 2014 13:51 > Para: tcmtf@ietf.org > Asunto: [tcmtf] Thank you for a great BoF! >=20 > Greetings, all, >=20 > Thanks to everyone for yesterday's BoF. We got lots of good input, and = a > better handle on what a future TCMTF WG might look like. >=20 > There are a few issues we identified that we'll have to take into > consideration for a new draft of the charter: >=20 > (1) make it clear that backward compatibility with RFC 4170 is a goal. >=20 > (2) an applicability statement, which explains applications that = benefit from > TCMTF and the situations for which it is likely useful, and applications > and situations for which it is not. This should address = interactions between > TCMTF tunnels and TCP cross traffic sharing a bottleneck link. >=20 > (3) interactions with how this interacts with diverse lower layers, especially > with respect to different delay tolerances, will have to be considered. >=20 > And we'd really more input from vendors already building boxes in this > space, and operators deploying them, as input to scoping and applicability. >=20 > Best regards, >=20 > Mirja and Brian (second TCMTF BoF chairs) > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf From nobody Wed Mar 5 09:19:06 2014 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0341A06D6 for ; Wed, 5 Mar 2014 09:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHm6wP7Ie6kS for ; Wed, 5 Mar 2014 09:18:57 -0800 (PST) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id A64161A06B8 for ; Wed, 5 Mar 2014 09:18:56 -0800 (PST) Received: from jsaldanapc (dhcp-a32b.meeting.ietf.org [31.133.163.43]) (authenticated bits=0) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s25HInI5012632 for ; Wed, 5 Mar 2014 18:18:50 +0100 From: "Jose Saldana" To: Date: Wed, 5 Mar 2014 17:18:51 -0000 Message-ID: <018c01cf3896$fb1bb2a0$f15317e0$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018D_01CF3896.FB1D6050" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac84lqA2ZObEFWLdRiC9jcB3UzmvaQ== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/tcmtf/ilMePMB4BfzU9a8z4k3eRlYJAvk Subject: [tcmtf] GAIA (Global Access to the Internet for All) session in London X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.15 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, 05 Mar 2014 17:18:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_018D_01CF3896.FB1D6050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, Tomorrow, 6th March, a meeting of the IRTF GAIA group will be held in London. The group is intended to enable a better Internet access to developing countries. Perhaps some of you may not have noticed, because this meeting is not in the IETF89 agenda. Regrettably, the sessions will not be broadcasted, but the slides will be made available here: http://trac.tools.ietf.org/group/irtf/trac/wiki/gaia Perhaps some of you may find the activities of this group interesting: https://irtf.org/mailman/listinfo/gaia. They are considering different technologies for providing Internet access to isolated places. Best regards, Jose ------=_NextPart_000_018D_01CF3896.FB1D6050 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,

Tomorrow, 6^th March, a meeting of the IRTF GAIA = group will be held in London. The group is intended to enable a better = Internet access to developing countries. Perhaps some of you may not = have noticed, because this meeting is not in the IETF89 = agenda.

Regrettably, the sessions will not be broadcasted, but the = slides will be made available here: http://trac.tools.ietf.org/group/irtf/trac/wiki/gaia<= /a>

Perhaps some of you may find the activities of this group = interesting: https://irtf.org/mailman/listinfo/gaia. They are considering different technologies for providing = Internet access to isolated places.

Best = regards,

Jose
------=_NextPart_000_018D_01CF3896.FB1D6050-- From nobody Wed Mar 5 12:41:32 2014 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9F81A0290 for ; Wed, 5 Mar 2014 12:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b41FGpaJqYzh for ; Wed, 5 Mar 2014 12:41:19 -0800 (PST) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 63AB61A0685 for ; Wed, 5 Mar 2014 12:41:18 -0800 (PST) Received: from jsaldanapc (outer-gw.ormecourt.com [46.65.2.55]) (authenticated bits=0) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s25Kf3LA015909; Wed, 5 Mar 2014 21:41:04 +0100 From: "Jose Saldana" To: "'Alexander Harrowell'" , References: In-Reply-To: Date: Wed, 5 Mar 2014 20:41:11 -0000 Message-ID: <00ef01cf38b3$3f116600$bd343200$@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: AQH4o+mSHwkN8DnViO6mUepwJ1DC35qAHeng Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/tcmtf/RCHn32MI2EJ4VcRgn_-XU-G260s Subject: Re: [tcmtf] Scenarios or Use Cases? X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.15 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, 05 Mar 2014 20:41:24 -0000 Alexander, You mean that the "examples" are the use cases. Do you think they should be put apart? I think the current structure is: - Scenario 1 - possible use cases in this scenario - Scenario 2 ... I don't know if putting them separately would be more clear or perhaps less... I would like to hear more opinions about this. Thanks! Jose > -----Mensaje original----- > De: tcmtf [mailto:tcmtf-bounces@ietf.org] En nombre de Alexander > Harrowell > Enviado el: mi=E9rcoles, 05 de marzo de 2014 13:09 > Para: tcmtf@ietf.org > Asunto: [tcmtf] Scenarios or Use Cases? >=20 > There was some discussion of this at the BOF in IETF 89. Re-reading, = there are > in fact use cases embedded in the scenarios, but as it stands I think = the > section mixes the use cases that motivate users with the description = of > where in a network it might be deployed. >=20 >=20 > Here's the relevant section of the I-D: >=20 >=20 > 1.4.1. Multidomain scenario >=20 > In this scenario, the TCMT-TF tunnel goes all the way from one network edge > (the place where users are attached to the ISP) to another, and = therefore it > can cross several domains. As shown in Figure 1, the optimization is > performed before the packets leave the domain of an ISP; the traffic crosses > the Internet tunnelized, and the packets are rebuilt in the second = domain. > _ _ _ _ _ _ > ( ' ) _ _ _ ( ' )_ _ > ( +------+ )') ( ' )_ ( +------+ ') > -->(_ -|TCM-IO|--- _) ---> ( ) ') ----->(_-|TCM-EO|--_)--> > ( +------+ _) (_ (_ . _) _) ( +------+ _) (_ _ _ _) (_ _ ( _) _) ISP 1 Internet ISP 2 <- > -----------------TCM-TF--------------------> > Figure 1 >=20 > Note that this is not from border to border (where ISPs connect to the > Internet, which could be covered with specialized links) but from an = ISP to > another (e.g. managing all traffic from individual users arriving at a Game > Provider, regardless users' location). >=20 > Some examples of this could be: >=20 > o An ISP could place a TCM optimizer in its aggregation network, in = order to > tunnel all the packets of a service, sending them to the application provider, > who would rebuild the packets before forwarding them to the = application > server. This would result in savings for both actors. >=20 > o A service provider (e.g., an online gaming company) could be allowed = to > place a TCM optimizer in the aggregation network of an ISP, being able = to > optimize all the flows of a game or service. > Another TCM optimizer would rebuild these packets once they arrive to = the > network of the provider. >=20 > 1.4.2. Single domain > TCM-TF is only activated inside an ISP, from the edge to border, = inside the > network operator. The geographical scope and network depth of TCM-TF > activation could be on demand, according to traffic conditions. >=20 > If we consider the residential users of a real-time interactive application (e.g., > VoIP, an online game generating small packets) in a town or a = district, a TCM > optimizing module can be included in network devices, in order to = group > packets with the same destination. > As shown in Figure 2, depending on the number of users of the = application, > the packets could be grouped at different levels in DSL fixed network > scenarios, at gateway level in LTE mobile network scenarios or even in other > ISP edge routers. TCM-TF may also be applied for fiber residential accesses, > and in 2G/3G mobile networks. > This would reduce bandwidth requirements in the provider aggregation > network >=20 > +------+ > N users -|TCM-IO|\ > +------+ \ > \ _ _ _ _ > +------+ \--> ( ' )_ +------+ ( ' )_ > M users -|TCM-IO|------> ( ) ') --|TCM-EO|--> ( ) ') > +------+ / ->(_ (_ . _) _) +------+ (_ (_ . _) _) > / > +------+ / ISP Internet > P users -|TCM-IO|/ > +------+ > <------------TCM-TF--------------> > Figure 2 >=20 > At the same time, the ISP would implement TCM-TF capabilities within = its > own MPLS network in order to optimize internal network resources: > optimizing modules could be embedded in the Label Edge Routers of the > network. In that scenario MPLS would be the "tunneling" layer, being = the > tunnels the paths defined by the MPLS labels and avoiding the use of = other > tunneling protocols. >=20 >=20 > Finally, some networks use cRTP [cRTP] in order to obtain bandwidth savings > on the access link, but as a counterpart it consumes considerable CPU > resources on the aggregation router. In these cases, by means of TCM, > instead of only saving bandwidth on the access link, it could also be saved > across the ISP network, without the CPU impact on the aggregation = router. >=20 > 1.4.3. Private solutions > End users can also optimize traffic end-to-end from network borders. > TCM-TF is used to connect private networks geographically apart (e.g. > corporation headquarters and subsidiaries), without the ISP being = aware (or > having to manage) those flows, as shown in Figure 3, where two = different > locations are connected through a tunnel traversing the Internet or another > network. >=20 > _ _ _ _ _ _ > ( ' )_ +------+ ( ' )_ +------+ ( ' )_ > ( ) ') --|TCM-IO|-->( ) ') --|TCM-EO|-->( ) ') (_ (_ . _) _) +------+ = (_ (_ . _) _) +- > -----+ (_ (_ . _)_) Location 1 ISP/Internet Location 2 <-----------TCM-TF--------- > -> Figure 3 >=20 > Some examples of these scenarios: >=20 > o The case of an enterprise with a number of distributed central = offices, in > which an appliance could be placed next to the access router, being = able to > optimize traffic flows with a shared origin and destination. Thus, a number of > remote desktop sessions to the same server could be optimized, or a > number of VoIP calls between two offices could also require less = bandwidth > and fewer packets per second. In some cases the tunnel is already = included > for security reasons, so the additional overhead of TCM-TF is lower. >=20 > o An Internet cafe, which is suitable of having many users of the same > application (e.g., VoIP, a game) sharing the same access link. = Internet cafes > are very popular in countries with relatively low access speeds in households, > where home computer penetration is usually low as well. In many of = these > countries, bandwidth can become a serious limitation for this kind of > business, so TCM-TF savings may become interesting for their = viability. >=20 >=20 > o Community networks [topology_CNs] (typically deployed in rural areas = or > in developing countries), in which a number of people in the same > geographical place share their connections in a cooperative way, and a > number of wireless hops are required in order to reach a router = connected to > the Internet. >=20 > o Satellite communication links that often manage the bandwidth by limiting > the transmission rate, measured in packets per second (pps), to and = from > the satellite. Applications like VoIP that generate a large number of small > packets can easily fill the maximum number of pps slots, limiting the > throughput across such links. As an example, a G.729a voice call = generates 50 > pps at 20 ms packetization time. If the satellite transmission allows 1,500 pps, > the number of simultaneous voice calls is limited to 30. > This results in poor utilization of the satellite link's bandwidth as = well as places > a low bound on the number of voice calls that can utilize the link > simultaneously. TCM optimization of small packets into one packet for > transmission would improve the efficiency. >=20 > o In a M2M/SCADA (Supervisory Control And Data Acquisition) context, = TCM > optimization can be applied when a satellite link is used for = collecting the data > of a number of sensors. M2M terminals are normally equipped with = sensing > devices which can interface to proximity sensor networks through = wireless > connections. The terminal can send the collected sensing data using a > satellite link connecting to a satellite gateway, which in turn will forward the > M2M/SCADA data to the to the processing and control center through > Internet. The size of typical M2M application transaction depends on = the > specific service and it may vary from a minimum of > 20 bytes (e.g., tracking and metering in private security) to about = 1,000 bytes > (e.g., video-surveillance). In this context, TCM-TF concepts can be = also > applied to allow a more efficient use of the available satellite link capacity, > matching the requirements demanded by some M2M services. If the case = of > large sensor deployments is considered, where proximity sensor = networks > transmit data through different satellite terminals, the use of compression > algorithms already available in current satellite systems to reduce = the > overhead introduced by UDP and IPv6 protocols is certainly desirable. = In > addition to this, tunneling and multiplexing functions available from TCM-TF > allows extending compression functionality throughout the rest the network, > to eventually reach the processing and control centers. >=20 > o Desktop or application sharing where the traffic from the server to = the > client typically consists of the delta of screen updates. >=20 > Also, the standard for remote desktop sharing emerging for WebRTC in = the > RTCWEB Working Group is: {something}/SCTP/UDP (Stream Control > Transmission Protocol [SCTP]). In this scenario, SCTP/UDP could be = used in > other cases: chatting, file sharing and applications related to WebRTC peers. > There could be hundreds of clients at a site talking to a server = located at a > datacenter over a WAN. Compressing, multiplexing and tunneling this traffic > could save WAN bandwidth and potentially improve latency. >=20 > 1.4.4. Mixed scenarios >=20 > Different combinations of the previous scenarios can be considered. > Agreements between different companies can be established in order to > save bandwidth and to reduce packets per second. As an example, Figure = 4 > shows a game provider that wants to TCM-optimize its connections by > establishing associations between different TCM-IO/EOs placed in the = game > server and several TCM-IO/EOs placed in the networks of different ISPs > (agreements between the game provider and each ISP would be = necessary). > In every ISP, the TCM-IO/EO would be placed in the most adequate point > (actually several TCM-IO/EOs could exist per ISP) in order to = aggregate > enough number of users. > _ _ > N users ( ' )_ > +---+ ( ) ') > |TCM|->(_ (_ . _) > +---+ ISP 1 \ > _ _ \ _ _ _ _ _ > M users ( ' )_ \ ( ' ) ( ' ) ( ' ) > +---+ ( ) ') \ ( ) ') ( ) ') +---+ ( ) ') > |TCM|->(_ (_ ._)---- (_ (_ . _) ->(_ (_ . _)->|TCM|->(_ (_ . _) > +---+ ISP 2 / Internet ISP 4 +---+ Game Provider > _ _ / ^ > O users ( ' )_ / | > +---+ ( ) ') / +---+ > |TCM|->(_ (_ ._) P users->|TCM| > +---+ ISP 3 +---+ > Figure 4 >=20 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf From nobody Tue Mar 11 02:35:28 2014 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0A41A03E2 for ; Tue, 11 Mar 2014 02:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ODNmPtOw8Nl for ; Tue, 11 Mar 2014 02:35:25 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 382771A0381 for ; Tue, 11 Mar 2014 02:35:24 -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 s2B9ZACg023803 for ; Tue, 11 Mar 2014 10:35:15 +0100 From: "Jose Saldana" To: Date: Tue, 11 Mar 2014 10:35:14 +0100 Message-ID: <000b01cf3d0d$382742c0$a875c840$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01CF3D15.99EC9520" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac89DTKZQT9YYS1+Tj++4ZX+f2Yk/Q== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/tcmtf/crqN_Xp7Asyy8oaV8DldfdV5WtA Subject: [tcmtf] The TCM-TF BoF minutes are available X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.15 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, 11 Mar 2014 09:35:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000C_01CF3D15.99EC9520 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, The BoF minutes have been uploaded here: http://www.ietf.org/proceedings/89/minutes/minutes-89-tcmtf Many thanks to Alan Ford and Sebastian Kiesel for taking notes! We are waiting for the decision of the ADs and the IESG about the WG creation. Best regards, Jose Saldana ------=_NextPart_000_000C_01CF3D15.99EC9520 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,

The BoF = minutes have been uploaded here: http= ://www.ietf.org/proceedings/89/minutes/minutes-89-tcmtf

Many thanks to Alan Ford and Sebastian = Kiesel for taking = notes!

We are waiting for the decision of the = ADs and the IESG about the WG creation.

Best regards,

Jose Saldana

------=_NextPart_000_000C_01CF3D15.99EC9520-- From nobody Wed Mar 12 01:23:33 2014 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172C01A0916 for ; Wed, 12 Mar 2014 01:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.034 X-Spam-Level: X-Spam-Status: No, score=-4.034 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ONE_TIME=0.714, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-0UBeagS_D9 for ; Wed, 12 Mar 2014 01:23:27 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 503751A08FA for ; Wed, 12 Mar 2014 01:23:26 -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 s2C8NEYN010897; Wed, 12 Mar 2014 09:23:14 +0100 From: "Jose Saldana" To: "Martin Stiemerling" References: <6FE75E93-FF8E-4435-B2D6-6A44668D5AA7@tik.ee.ethz.ch> In-Reply-To: Date: Wed, 12 Mar 2014 09:23:18 +0100 Message-ID: <008301cf3dcc$52b8f6f0$f82ae4d0$@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: AQHzuOG1bU6Xk0Mlov/nfhNUFohXjwJwnHIamoCe0sA= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/tcmtf/fmUHoPrjDgyKatHUlbvxfN7qcPU Cc: tcmtf@ietf.org, 'Spencer Dawkins' Subject: [tcmtf] RV: Thank you for a great BoF! X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.15 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, 12 Mar 2014 08:23:30 -0000 Hi, Martin, According to the summary of Brian and Mirja, there are three potential improvements for the TCM-TF charter draft. I have added some comments = below. Should we prepare a new version of the charter? > -----Mensaje original----- > De: tcmtf [mailto:tcmtf-bounces@ietf.org] En nombre de Brian Trammell > Enviado el: mi=E9rcoles, 05 de marzo de 2014 14:51 > Para: tcmtf@ietf.org > Asunto: [tcmtf] Thank you for a great BoF! >=20 > Greetings, all, >=20 > Thanks to everyone for yesterday's BoF. We got lots of good input, and = a > better handle on what a future TCMTF WG might look like. >=20 > There are a few issues we identified that we'll have to take into > consideration for a new draft of the charter: >=20 > (1) make it clear that backward compatibility with RFC 4170 is a goal. I think there is no problem with maintaining backwards compatibility. I = sent some suggestions for improving the charter: http://www.ietf.org/mail-archive/web/tcmtf/current/msg00524.html >=20 > (2) an applicability statement, which explains applications that = benefit from > TCMTF and the situations for which it is likely useful, and applications > and situations for which it is not. The current n.4 of the charter is about this (http://www.ietf.org/mail-archive/web/tcmtf/current/msg00493.html) = Should we improve it?: 4. New scenarios where bandwidth savings are desirable have been = identified, in addition to those considered in RFC4170. In these scenarios, there = are moments or places where network capacity gets scarce, so allocating more bandwidth is a possible solution, but it implies a recurring cost. = However, the inclusion of a pair of boxes able to optimize the traffic when/where required is a one-time investment. These scenarios can be classified = into: * Multidomain, the TCMT-TF tunnel goes all the way from one network edge = to another, and can therefore cross several domains. * Single Domain, TCM-TF is only activated inside an ISP, from the edge = to border inside the network operator. * Private Solutions. TCM-TF is used to connect private networks geographically apart (e.g. corporation headquarters and subsidiaries), without the ISP being aware or having to manage those flows. * Mixed Scenarios, any combination of the previous ones. > This should address interactions between > TCMTF tunnels and TCP cross traffic sharing a bottleneck link. This should have to be added to the charter, but I don't clearly = understand what is this problem about. If we compress UDP flows, then we have more bandwidth for TCP flows sharing the bottleneck. Where is the problem? Perhaps I missed something in the discussion. >=20 > (3) interactions with how this interacts with diverse lower layers, especially > with respect to different delay tolerances, will have to be considered. >=20 Is this covered by n.7? Perhaps some sentences could be added: 7. As a counterpart of the bandwidth saving, TCM-TF may add some delay = and jitter. This is not a problem for the services which are not sensitive = to delay. However, regarding delay-sensitive services, the Working Group = will also develop a document (TCM-TF - recommendations) with useful recommendations in order to decide which packet flows can or can not be multiplexed and how. The document will present a list of available = traffic classification methods which can be used for identification of the = service or application to which a particular flow belongs, as well as recommendations of the maximum delay and jitter to be added depending of = the identified service or application. The eventual impact of multiplexing = on protocol dynamics (e.g. the loss of a multiplexed packet, MTU-related issues) will also have to be addressed. > And we'd really more input from vendors already building boxes in this > space, and operators deploying them, as input to scoping and applicability. >=20 We have some messages in the list: http://www.ietf.org/mail-archive/web/tcmtf/current/msg00490.html http://www.ietf.org/mail-archive/web/tcmtf/current/msg00497.html http://www.ietf.org/mail-archive/web/tcmtf/current/msg00491.html http://www.ietf.org/mail-archive/web/tcmtf/current/msg00498.html > Best regards, >=20 > Mirja and Brian (second TCMTF BoF chairs) > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf Thanks a lot, Jose From nobody Wed Mar 12 02:00:07 2014 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D55A1A092A for ; Wed, 12 Mar 2014 02:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCr6RyrGb806 for ; Wed, 12 Mar 2014 02:00:02 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 401421A091F for ; Wed, 12 Mar 2014 02:00:02 -0700 (PDT) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) by trammell.ch (Postfix) with ESMTPSA id ABBEE1A1077; Wed, 12 Mar 2014 09:59:54 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_E95494B2-B819-47C7-AE97-B74FA76365DA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 $1874$) From: Brian Trammell In-Reply-To: <008301cf3dcc$52b8f6f0$f82ae4d0$@unizar.es> Date: Wed, 12 Mar 2014 09:59:53 +0100 Message-Id: <6B8F7D52-625E-4502-B87E-B2D399B6B023@trammell.ch> References: <6FE75E93-FF8E-4435-B2D6-6A44668D5AA7@tik.ee.ethz.ch> <008301cf3dcc$52b8f6f0$f82ae4d0$@unizar.es> To: Jose Saldana X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/tcmtf/ryGZYuwttizH_CuquIy7vbtifsw Cc: tcmtf@ietf.org, Martin Stiemerling , Spencer Dawkins Subject: Re: [tcmtf] Thank you for a great BoF! X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.15 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, 12 Mar 2014 09:00:06 -0000 --Apple-Mail=_E95494B2-B819-47C7-AE97-B74FA76365DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Greetings, all, (as individual contributor, BoF chair hat off since, indeed, the BoF is = over. :) ) A couple of points, inline... On 12 Mar 2014, at 09:23, Jose Saldana wrote: > Hi, Martin, >=20 > According to the summary of Brian and Mirja, there are three potential > improvements for the TCM-TF charter draft. I have added some comments = below. >=20 > Should we prepare a new version of the charter? >=20 >> -----Mensaje original----- >> De: tcmtf [mailto:tcmtf-bounces@ietf.org] En nombre de Brian Trammell >> Enviado el: mi=E9rcoles, 05 de marzo de 2014 14:51 >> Para: tcmtf@ietf.org >> Asunto: [tcmtf] Thank you for a great BoF! >>=20 >> Greetings, all, >>=20 >> Thanks to everyone for yesterday's BoF. We got lots of good input, = and a >> better handle on what a future TCMTF WG might look like. >>=20 >> There are a few issues we identified that we'll have to take into >> consideration for a new draft of the charter: >>=20 >> (1) make it clear that backward compatibility with RFC 4170 is a = goal. >=20 > I think there is no problem with maintaining backwards compatibility. = I sent > some suggestions for improving the charter: > http://www.ietf.org/mail-archive/web/tcmtf/current/msg00524.html While it was _somewhat_ clear that backward compatibility was desired, = it wasn't explicit in the charter, and some people found that confusing. = Simply making it explicit (i.e., ensuring the phrase "backward = compatible with 4170" appears in the charter text) fixes this problem. >> This should address interactions between >> TCMTF tunnels and TCP cross traffic sharing a bottleneck link. >=20 > This should have to be added to the charter, but I don't clearly = understand > what is this problem about. If we compress UDP flows, then we have = more > bandwidth for TCP flows sharing the bottleneck. Where is the problem? > Perhaps I missed something in the discussion. If you're compressing UDP flows to get them out of the way of concurrent = TCP traffic, this is what you want. It's a problem if the reason you're = doing UDP header compression is to get more bandwidth for UDP flows, or = to reduce losses on the UDP flows on a congested link, since concurrent = TCP traffic will always use all the bandwidth it can while inducing = packet loss (necessary for the operation of loss-based congestion = control) on all flows sharing the bottleneck link. This is a key point to account for when running TCP and TCM across the = same bottleneck link: congestion control will induce loss, implying that = any header compression scheme in such a scenario will have to be = relatively loss tolerant. I'm not really up on the details of the = compression technologies proposed, but we'll have to have a good = understanding of the packet loss amplification properties thereof. RFC = 3545 seems to imply that ECRTP is relatively loss and reordering = tolerant. ROHC is rather a complicated specification so a five-minute = analysis of its loss tolerance is not really possible, but I presume = they thought of it. A quick read of RFC 2057 section 3.3 seems to imply = that IPHC can amplify loss with high rates of context change, but I have = no idea how this actually works or does not work in practice. The point = is that the point will have to be addressed, either by ensuring that all = header compression is relatively loss tolerant for common CC-induced = loss rates, or by using lower-layer tricks to segregate TCM from TCP = traffic. This is definitely content for the applicability statement, and the = ability to meet these goals for a given use case should be a criteria = for determining whether or not that use case is in or out of scope for = TCMTF. >> And we'd really more input from vendors already building boxes in = this >> space, and operators deploying them, as input to scoping and > applicability. >>=20 > We have some messages in the list: > http://www.ietf.org/mail-archive/web/tcmtf/current/msg00490.html > http://www.ietf.org/mail-archive/web/tcmtf/current/msg00497.html > http://www.ietf.org/mail-archive/web/tcmtf/current/msg00491.html > http://www.ietf.org/mail-archive/web/tcmtf/current/msg00498.html Indications of interest are great. Contributions to eventual documents = are even better. :) Cheers, Brian --Apple-Mail=_E95494B2-B819-47C7-AE97-B74FA76365DA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTICIKAAoJENt3nsOmbNJcWy0IAIEaITvxDnDNKzuI6OKRmMlD 4K+eW1w646fPrLHpZgYe/k26lYBN6VDD/IYznpvb6gbtCM3xT0Gcp31C7eyfggGy eBk3XuP8CyP4TulCJrb6l2DVz80EFKw/VLUvBiLg2u73FBzEGBZ8Gb3cnNLe1v8/ 8rTBGIwFne7k4v5SHMjKCiawmHFw59IFXUdSpbQbjPz6M5c4oykPZ8eCvWf6WMwA WS33aRbechViob3UQWFqX1oqasN9Kt1Xvr5pTTq7++FCFglZYmDdybmgWNyCjGre HovcKV8Bw2KUhJQv+yHrcccjyrHW7FIQX/LZUnzUS+v9pDhAkvdRfakxfIHpLgI= =ULXY -----END PGP SIGNATURE----- --Apple-Mail=_E95494B2-B819-47C7-AE97-B74FA76365DA-- From nobody Thu Mar 13 04:03:49 2014 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A611A09D6 for ; Thu, 13 Mar 2014 04:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOp4nSQQZBl0 for ; Thu, 13 Mar 2014 04:03:44 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 943DA1A09D4 for ; Thu, 13 Mar 2014 04:03:43 -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 s2DB3W4f027813; Thu, 13 Mar 2014 12:03:32 +0100 From: "Jose Saldana" To: "'Brian Trammell'" References: <6FE75E93-FF8E-4435-B2D6-6A44668D5AA7@tik.ee.ethz.ch> <008301cf3dcc$52b8f6f0$f82ae4d0$@unizar.es> <6B8F7D52-625E-4502-B87E-B2D399B6B023@trammell.ch> In-Reply-To: <6B8F7D52-625E-4502-B87E-B2D399B6B023@trammell.ch> Date: Thu, 13 Mar 2014 12:03:35 +0100 Message-ID: <012301cf3eab$e153d0d0$a3fb7270$@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: AQHzuOG1bU6Xk0Mlov/nfhNUFohXjwJwnHIaAX1/GgoCmveixpphmEzA Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/tcmtf/K3L7-xtCHjaRLrza0psjYqwELnY Cc: tcmtf@ietf.org, 'Martin Stiemerling' , 'Spencer Dawkins' Subject: Re: [tcmtf] Thank you for a great BoF! X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 11:03:49 -0000 Thanks, Brian! I will send a new charter in five minutes including these things: modifications in n. 3, 5 and milestones; a new n.8. Comments inline. > -----Mensaje original----- > De: tcmtf [mailto:tcmtf-bounces@ietf.org] En nombre de Brian Trammell > Enviado el: mi=E9rcoles, 12 de marzo de 2014 10:00 > Para: Jose Saldana > CC: tcmtf@ietf.org; Martin Stiemerling; Spencer Dawkins > Asunto: Re: [tcmtf] Thank you for a great BoF! >=20 > Greetings, all, >=20 > (as individual contributor, BoF chair hat off since, indeed, the BoF = is over. :) > ) >=20 > A couple of points, inline... >=20 > On 12 Mar 2014, at 09:23, Jose Saldana wrote: >=20 > > Hi, Martin, > > > > According to the summary of Brian and Mirja, there are three = potential > > improvements for the TCM-TF charter draft. I have added some = comments > below. > > > > Should we prepare a new version of the charter? > > > >> -----Mensaje original----- > >> De: tcmtf [mailto:tcmtf-bounces@ietf.org] En nombre de Brian = Trammell > >> Enviado el: mi=E9rcoles, 05 de marzo de 2014 14:51 > >> Para: tcmtf@ietf.org > >> Asunto: [tcmtf] Thank you for a great BoF! > >> > >> Greetings, all, > >> > >> Thanks to everyone for yesterday's BoF. We got lots of good input, > >> and a better handle on what a future TCMTF WG might look like. > >> > >> There are a few issues we identified that we'll have to take into > >> consideration for a new draft of the charter: > >> > >> (1) make it clear that backward compatibility with RFC 4170 is a = goal. > > > > I think there is no problem with maintaining backwards = compatibility. > > I sent some suggestions for improving the charter: > > http://www.ietf.org/mail-archive/web/tcmtf/current/msg00524.html >=20 > While it was _somewhat_ clear that backward compatibility was desired, = it > wasn't explicit in the charter, and some people found that confusing. Simply > making it explicit (i.e., ensuring the phrase "backward compatible = with > 4170" appears in the charter text) fixes this problem. >=20 > I have modified points 3, 5 and milestones so as to maintain backwards compatibility with RFC4170. >=20 > >> This should address interactions between > >> TCMTF tunnels and TCP cross traffic sharing a bottleneck link. > > > > This should have to be added to the charter, but I don't clearly > > understand what is this problem about. If we compress UDP flows, = then > > we have more bandwidth for TCP flows sharing the bottleneck. Where = is > the problem? > > Perhaps I missed something in the discussion. >=20 > If you're compressing UDP flows to get them out of the way of = concurrent > TCP traffic, this is what you want. It's a problem if the reason = you're doing > UDP header compression is to get more bandwidth for UDP flows, or to > reduce losses on the UDP flows on a congested link, since concurrent = TCP > traffic will always use all the bandwidth it can while inducing packet loss > (necessary for the operation of loss-based congestion control) on all flows > sharing the bottleneck link. >=20 > This is a key point to account for when running TCP and TCM across the same > bottleneck link: congestion control will induce loss, implying that = any > header compression scheme in such a scenario will have to be = relatively > loss tolerant. I'm not really up on the details of the compression > technologies proposed, but we'll have to have a good understanding of = the > packet loss amplification properties thereof. RFC 3545 seems to imply = that > ECRTP is relatively loss and reordering tolerant. ROHC is rather a > complicated specification so a five-minute analysis of its loss = tolerance is > not really possible, but I presume they thought of it. A quick read of = RFC > 2057 section 3.3 seems to imply that IPHC can amplify loss with high = rates of > context change, but I have no idea how this actually works or does not work > in practice. The point is that the point will have to be addressed, = either by > ensuring that all header compression is relatively loss tolerant for common > CC-induced loss rates, or by using lower-layer tricks to segregate TCM from > TCP traffic. The objective of ROHC was to build a "robust" header compression = mechanism, i.e. robust against context desynchronization. So the main idea is that = it can work over lossy links, much better than older header compression mechanisms (ECRTP, IPHC). So we could perhaps suggest that the loss rate = has to be taken into account during the negotiation of the header = compression protocol to be used. I mean: - If we are considering a congested link, or a wireless link, ROHC can = be the best choice. - If the link is not too congested, or it is wired (very low packet loss rate), other options can be considered, since they present less computational requirements. We could add this text to the charter. Something like this: 8. The TCM-TF =96 recommendations document will also provide information = about the best suited header compression protocol for each scenario. When = traffic is being compressed over a lossy link (wireless, high amount of = background traffic, etc.), an algorithm with better robustness against context desynchronization (i.e. ROHC) will be desirable; however, if compression = is being deployed in a link presenting a low packet loss rate (dedicated = links, wired scenarios), simpler algorithms (i.e. IPHC, ECRTP) can be used, = since they present less processing requirements. >=20 > This is definitely content for the applicability statement, and the ability to > meet these goals for a given use case should be a criteria for = determining > whether or not that use case is in or out of scope for TCMTF. >=20 > >> And we'd really more input from vendors already building boxes in > >> this space, and operators deploying them, as input to scoping and > > applicability. > >> > > We have some messages in the list: > > http://www.ietf.org/mail-archive/web/tcmtf/current/msg00490.html > > http://www.ietf.org/mail-archive/web/tcmtf/current/msg00497.html > > http://www.ietf.org/mail-archive/web/tcmtf/current/msg00491.html > > http://www.ietf.org/mail-archive/web/tcmtf/current/msg00498.html >=20 > Indications of interest are great. Contributions to eventual documents = are > even better. :) >=20 > Cheers, >=20 > Brian Cheers, Jose From nobody Thu Mar 13 04:23:44 2014 Return-Path: X-Original-To: tcmtf@ietfa.amsl.com Delivered-To: tcmtf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F14D1A0950 for ; Thu, 13 Mar 2014 04:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.033 X-Spam-Level: X-Spam-Status: No, score=-4.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, ONE_TIME=0.714, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4AhweQFnv7O for ; Thu, 13 Mar 2014 04:23:36 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 76E6F1A095C for ; Thu, 13 Mar 2014 04:23:35 -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 s2DBNMIL002199; Thu, 13 Mar 2014 12:23:22 +0100 From: "Jose Saldana" To: Date: Thu, 13 Mar 2014 12:23:28 +0100 Message-ID: <012401cf3eae$a8700920$f9501b60$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0125_01CF3EB7.0A35F7C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8+rqM6fGPQYqmWTxeFv4jp0DDBhg== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/tcmtf/3Rqz3_ovwflk9BrZgcGWzlIBXLU Cc: Martin Stiemerling , 'Spencer Dawkins' Subject: [tcmtf] New version of the TCM-TF charter draft (v12) X-BeenThere: tcmtf@ietf.org X-Mailman-Version: 2.1.15 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, 13 Mar 2014 11:23:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0125_01CF3EB7.0A35F7C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit According to the received feedback, this is a new version of the draft charter (v12). The changes are summarized here: http://www.ietf.org/mail-archive/web/tcmtf/current/msg00530.html Tunneling Compressed Multiplexed Traffic Flows (TCM-TF) charter draft v12 Description of Working Group 1. RFC4170 (TCRTP) defines a method for grouping packets when a number of UDP/RTP VoIP flows share a common path, considering three different layers: ECRTP header compression; PPPMux multiplexing; L2TPv3 tunneling. TCRTP optimizes the traffic, increasing the bandwidth efficiency of VoIP and reduces the amount of packets per second at the same time. 2. However, in the last years, emerging real-time services which use bare UDP instead of UDP/RTP have become popular. Due to the need of interactivity, many of these services use small packets (some tens of bytes). Some other services also send small packets, but they are not delay-sensitive (e.g., instant messaging, m2m packets in sensor networks). In addition, a significant effort has been devoted to the deployment of new header compression methods with improved robustness (ROHC). 3. So there is a need of adding new options to the one considered in RFC4170, thus building an extended solution able to optimize these new flows, also using improved compression methods. The same structure of three layers will be considered: * Header compression: different protocols can be used: no compression, ECRTP, IPHC and ROHC. * Multiplexing: PPPMux will be the option. * Tunneling: the options in this layer are L2TP, GRE and MPLS. 4. New scenarios where bandwidth savings are desirable have been identified, in addition to those considered in RFC4170. In these scenarios, there are moments or places where network capacity gets scarce, so allocating more bandwidth is a possible solution, but it implies a recurring cost. However, the inclusion of a pair of boxes able to optimize the traffic when/where required is a one-time investment. These scenarios can be classified into: * Multidomain, the TCMT-TF tunnel goes all the way from one network edge to another, and can therefore cross several domains. * Single Domain, TCM-TF is only activated inside an ISP, from the edge to border inside the network operator. * Private Solutions. TCM-TF is used to connect private networks geographically apart (e.g. corporation headquarters and subsidiaries), without the ISP being aware or having to manage those flows. * Mixed Scenarios, any combination of the previous ones. 5. A first document (TCM-TF - reference model) will define the different options which can be used at each layer. It will include a detailed specification of the scenarios of interest. Specific problems caused by the interaction between layers will have to be issued, and suitable extensions may have to be added to the involved protocols. The impact on other protocols will also be studied. However, the development of new compressing, multiplexing or tunneling protocols is not an objective of this Working Group. In addition, backwards compatibility with RFC 4170 will be granted, since it will be considered as one of the optimization options. 6. Since standard protocols are being considered at each layer, the signaling methods of those protocols will be used. Thus, interactions with the Working Groups and Areas in which these protocols are developed can be expected. Taking into account that different options will be considered when a pair of TCM-TF optimizers want to establish a session, they will have first to negotiate which concrete option would they use in each layer. This will depend on the protocols that each extreme implements at each level, and in the scenario. So another document (TCM-TF - negotiation protocol) will include: * a mechanism to setup/release a TCM-TF session between an ingress and an egress-optimizer, also including: * a negotiation mechanism to decide the options to use at each layer . 7. As a counterpart of the bandwidth saving, TCM-TF may add some delay and jitter. This is not a problem for the services which are not sensitive to delay. However, regarding delay-sensitive services, the Working Group will also develop a document (TCM-TF - recommendations) with useful recommendations in order to decide which packet flows can or can not be multiplexed and how. The document will present a list of available traffic classification methods which can be used for identification of the service or application to which a particular flow belongs, as well as recommendations of the maximum delay and jitter to be added depending of the identified service or application. The eventual impact of multiplexing on protocol dynamics (e.g. the loss of a multiplexed packet, MTU-related issues) will also have to be addressed. 8. The TCM-TF - recommendations document will also provide information about the best suited header compression protocol for each scenario. When traffic is being compressed over a lossy link (wireless, high amount of background traffic, etc.), an algorithm with better robustness against context desynchronization (i.e. ROHC) will be desirable; however, if compression is being deployed in a link presenting a low packet loss rate (dedicated links, wired scenarios), simpler algorithms (i.e. IPHC, ECRTP) can be used, since they present less processing requirements. 9. The working group may identify additional deliverables that are necessary/useful, e.g., a mechanism for a TCM-ingress optimizer to discover an egress optimizer, and vice versa. The working group would re-charter to add them before working on them. 10. Interactions with other Working Groups can be expected, since TCM-TF uses already defined protocols for compression, multiplexing and tunneling (ROHC, PPPMux, MPLS, GRE, L2TP). Goals and Milestones Specification of TCM-TF reference model and the scenarios of interest. Backwards compatibility with RFC4170 will be granted. Specification of TCM-TF negotiation protocol. Specification of TCM-TF recommendations of using existing traffic classification methods, maximum delay and jitter to add, depending on the service. Current version of Document (TCM-TF - reference model): https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/ Current version of Document (TCM-TF - recommendations): http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ Best regards, Jose ------=_NextPart_000_0125_01CF3EB7.0A35F7C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
According to the received feedback, = this is a new version of the draft charter (v12). The changes are = summarized here:
http://www.ietf.org/mail-archive/web/tcmtf/current/msg00530.html

= Tunneling Compressed Multiplexed Traffic Flows (TCM-TF) charter draft = v12
=
= Description of Working Group
=
= 1. RFC4170 (TCRTP) defines a method for grouping packets when a number = of UDP/RTP VoIP flows share a common path, considering three different = layers: ECRTP header compression; PPPMux multiplexing; L2TPv3 tunneling. = TCRTP optimizes the traffic, increasing the bandwidth efficiency of VoIP = and reduces the amount of packets per second at the same = time.
= 2. However, in the last years, emerging real-time services which use = bare UDP instead of UDP/RTP have become popular. Due to the need of = interactivity, many of these services use small packets (some tens of = bytes). Some other services also send small packets, but they are not = delay-sensitive (e.g., instant messaging, m2m packets in sensor = networks). In addition, a significant effort has been devoted to the = deployment of new header compression methods with improved robustness = (ROHC).
= 3. So there is a need of adding new options to the one considered in = RFC4170, thus building an extended solution able to optimize these new = flows, also using improved compression methods. The same structure of = three layers will be considered:
= * Header compression: different protocols can be used: no compression, = ECRTP, IPHC and ROHC.
= * Multiplexing: PPPMux will be the option.
= * Tunneling: the options in this layer are L2TP, GRE and = MPLS.
= 4. New scenarios where bandwidth savings are desirable have been = identified, in addition to those considered in RFC4170. In these = scenarios, there are moments or places where network capacity gets = scarce, so allocating more bandwidth is a possible solution, but it = implies a recurring cost. However, the inclusion of a pair of boxes able = to optimize the traffic when/where required is a one-time investment. = These scenarios can be classified into:
= * Multidomain, the TCMT-TF tunnel goes all = the way from one network edge to another, and can therefore cross = several domains.
= * Single Domain, TCM-TF is only activated inside an ISP, from the edge = to border inside the network operator.
= * Private Solutions. TCM-TF is used to connect private networks = geographically apart (e.g. corporation headquarters and subsidiaries), = without the ISP being aware or having to manage those = flows.
= * Mixed Scenarios, any combination of the previous = ones.
= 5. A first document (TCM-TF - reference model) will define the different = options which can be used at each layer. It will include a detailed = specification of the scenarios of interest. Specific problems caused by = the interaction between layers will have to be issued, and suitable = extensions may have to be added to the involved protocols. The impact on = other protocols will also be studied. However, the development of new = compressing, multiplexing or tunneling protocols is not an objective of = this Working Group. In addition, backwards compatibility with RFC 4170 = will be granted, since it will be considered as one of the optimization = options.
= 6. Since standard protocols are being considered at each layer, the = signaling methods of those protocols will be used. Thus, interactions = with the Working Groups and Areas in which these protocols are developed = can be expected. Taking into account that different options will be = considered when a pair of TCM-TF optimizers want to establish a session, = they will have first to negotiate which concrete option would they use = in each layer. This will depend on the protocols that each extreme = implements at each level, and in the scenario. So another document = (TCM-TF - negotiation protocol) will include:
= * a mechanism to setup/release a TCM-TF session between an ingress and = an egress-optimizer, also including:
= * a negotiation mechanism to decide the options to use at each layer = .
= 7. As a counterpart of the bandwidth saving, TCM-TF may add some delay = and jitter. This is not a problem for the services which are not = sensitive to delay. However, regarding delay-sensitive services, the = Working Group will also develop a document (TCM-TF - recommendations) = with useful recommendations in order to decide which packet flows can or = can not be multiplexed and how. The document = will present a list of available traffic classification methods which = can be used for identification of the service or application to which a = particular flow belongs, as well as recommendations of the maximum delay = and jitter to be added depending of the identified service or = application. The eventual impact of multiplexing on protocol dynamics = (e.g. the loss of a multiplexed packet, MTU-related issues) will also = have to be addressed.
= 8. The TCM-TF – recommendations document will also provide = information about the best suited header compression protocol for each = scenario. When traffic is being compressed over a lossy link (wireless, high amount of background = traffic, etc.), an algorithm with better robustness against context = desynchronization (i.e. ROHC) will be desirable; however, if compression = is being deployed in a link presenting a low packet loss rate (dedicated = links, wired scenarios), simpler algorithms (i.e. IPHC, ECRTP) can be = used, since they present less processing = requirements.
= 9. The working group may identify additional deliverables that are = necessary/useful, e.g., a mechanism for a TCM-ingress optimizer to = discover an egress optimizer, and vice versa. The working group would = re-charter to add them before working on them.
= 10. Interactions with other Working Groups can be expected, since TCM-TF = uses already defined protocols for compression, multiplexing and = tunneling (ROHC, PPPMux, MPLS, GRE, L2TP).
=
= Goals and Milestones=
= Specification of TCM-TF reference model and the scenarios of interest. = Backwards compatibility with RFC4170 will be = granted.
= Specification of TCM-TF negotiation protocol.
= Specification of TCM-TF recommendations of using existing traffic = classification methods, maximum delay and jitter to add, depending on = the service.
=
= Current version of Document (= TCM-TF - reference model= ):
= https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/=
= Current version of Document (= TCM-TF - recommendations= ):
= http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/=

Best regards,

Jose

------=_NextPart_000_0125_01CF3EB7.0A35F7C0--