Re: [tcmtf] TCM-TF: New Scenarios section
FERNANDO PASCUAL BLANCO <fpb@tid.es> Wed, 11 December 2013 17:00 UTC
Return-Path: <fpb@tid.es>
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 2DE5B1AE101; Wed, 11 Dec 2013 09:00:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Level:
X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 QrGClgZEXUZk; Wed, 11 Dec 2013 09:00:49 -0800 (PST)
Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 21E5A1ADF80; Wed, 11 Dec 2013 09:00:43 -0800 (PST)
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 <0MXN009OMJ8ZJY@tid.hi.inet>; Wed, 11 Dec 2013 18:00:35 +0100 (MET)
Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 11.3B.03314.33A98A25; Wed, 11 Dec 2013 18:00:35 +0100 (CET)
Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MXN009ODJ8ZJY@tid.hi.inet>; Wed, 11 Dec 2013 18:00:35 +0100 (MET)
Received: from EX10-MB1-MAD.hi.inet ([169.254.1.153]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Wed, 11 Dec 2013 18:00:34 +0100
Date: Wed, 11 Dec 2013 17:00:33 +0000
From: FERNANDO PASCUAL BLANCO <fpb@tid.es>
In-reply-to: <003701cef01a$c50729c0$4f157d40$@unizar.es>
X-Originating-IP: [10.95.64.115]
To: Jose Saldana <jsaldana@unizar.es>
Message-id: <22E08AA3-35E0-4F52-8108-5EB3E6A51880@tid.es>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_b4Zhh4EZBlIeNpUdEfX+oA)"
Content-language: en-US
Accept-Language: en-US, es-ES
Thread-topic: [tcmtf] TCM-TF: New Scenarios section
Thread-index: Ac7wGX3qs7myIgA/Tcy5mf6/uzleCgGcKOyA
X-AuditID: 0a5f4068-b7fe58e000000cf2-c8-52a89a330435
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsXCFe/ApWs8a0WQwaMbUha7Pm9gtFjwZjGz A5PHkiU/mQIYo7hsUlJzMstSi/TtErgy9ry7yl6w9xhLxf7+I2wNjI1vmbsYOTkkBEwkztz9 CWWLSVy4t56ti5GLQ0jgAKPElLttTBDOE0aJye1fWSGcmYwShyZPYwNpYRFQlVhyZxFYO5uA lsTpu6tYQGxhASOJRQ3XwWxOAQuJ88+OMEKsUJD4c+4xWFwEqHfp2d9gG5gFNjJKXJjVCTaI V8BSouPuHFYIW1Dix+R7YA3MAtESqzsPs0PY4hLNrTfB4owCshLv5s9nhRhqLDF9ZyeUbSQx +dE6FojFAhJL9pyH+lNU4uXjf2A1QgLmEos/zGWfwCg2C8m6WUjWzUKyDsI2kHh/bj4zhK0t sWzhayhbX2Ljl7OMELaZxIol+1mQ1Sxg5FjFKFacVJSZnlGSm5iZk25gqJeRqZeZl1qyiRES oRk7GJfvVDnEKMDBqMTDe6BoeZAQa2JZcWXuIUYJDmYlEd61NSuChHhTEiurUovy44tKc1KL DzEycXBKNTDO0vKoe+rX+OGE3DNXhqS5nw467J6rIHh72cGTLsYfTCp6DvOc5Fs+V+jvjPvr U62dTlwrTz6h/lchf/+HDf9l5s6yUV3/+NEJOy37j4aHv89l3ng0KF3m6dfFgSuD4uZ12ph9 +q1dX8/r/+BC3RNzrf8hF/dxuuxt/d08/8MacwV344eL1k57psRSnJFoqMVcVJwIABiH1QKu AgAA
References: <003701cef01a$c50729c0$4f157d40$@unizar.es>
Cc: "tcmtf@ietf.org" <tcmtf@ietf.org>, Martin Stiemerling <mls.ietf@googlemail.com>, "tsv-area@ietf.org" <tsv-area@ietf.org>, Spencer Dawkins <spencerdawkins.ietf@gmail.com>
Subject: Re: [tcmtf] TCM-TF: New Scenarios section
X-BeenThere: tcmtf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Tunneling Compressed Multiplexed Traffic Flows \(TCMTF\) discussion list" <tcmtf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcmtf/>
List-Post: <mailto:tcmtf@ietf.org>
List-Help: <mailto:tcmtf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 17:00:56 -0000
Hi Jose, I agree with the scenario classification. It is general enough to englobe the different TCM-TF possibilities. Just a couple of things: * When you say “...with the same destination. As shown in Figure 1, depending on the number..” I think you actually refer to Figure 2. * I have one application scenario in my mind that I´m not able to fit in one of the presented scenarios (but I do in a mix of scenario 1.4.1 and 1.4.2): what about a gaming provider that wants to TCM-optimize it game server connection by establishing associations between its TCM-IO/EO placed in the game server and several TCM-IO/EO placed in different ISPs (agreements would be necessary between the game provider and every ISP)? Let me try by drawing in ASCII: _ _ ( ` )_ +---------+ ( ) `) N-users -|TCM-IO/EO|--> (_ (_ . _) _) -- +---------+ ISP 2 \ _ _ \ _ _ _ _ _ _ ( ` )_ \ ( ` ) ( ` ) ( ` ) +---------+ ( ) `) \-> ( ) `) ( ) `) +---------+ ( ) `) M-users -|TCM-IO/EO|--> (_ (_ . _) _) --------> (_ (_ . _) _) ----> (_ (_ . _) _) ----> -|TCM-IO/EO|---> (_ (_ . _) _) +---------+ ISP 3 /-> Internet ISP 1 +---------+ Game Provider _ _ / ^ ( ` )_ / | +---------+ ( ) `) -- / +---------+ O-users -|TCM-IO/EO|--> (_ (_ . _) _) P-users --|TCM-IO/EO| +---------+ ISP 4 +---------+ In every ISP the TCM-IO/EO would be placed in the more appropriate point (actually it could be several TCM-IO/EO per ISP) in order to aggregate the correct number of users (as in scenario 1.4.2). Do you think it is a useful scenario to describe or it is not necessary assuming that it could be seen as a mix of basic scenarios? Regards, Fernando Fernando Pascual Blanco Network Automation and Dynamization | Telefonica Global Resources C/ Don Ramón de la Cruz 82-84, 28006, Madrid, España fpb@tid.es<mailto:jessica.iglesiascarrera@telefonica.com> |F +34 91 312 8779 | M +34 682 005 168 On 03/12/2013, at 12:28, Jose Saldana <jsaldana@unizar.es<mailto:jsaldana@unizar.es>> wrote: Hi all. I am working on the next version of the TCM-TF “reference model” draft. I have re-written the Scenarios section, according to David’s classification, and taking into account the discussion of the last weeks. So I would like to hear your opinion. I have also included three new figures. Thanks a lot! Jose 1.4. Scenarios of application Different scenarios of application can be considered for the tunneling, compressing and multiplexing solution. They can be classified according to the domains involved in the optimization: 1.4.1. Multidomain scenario In this scenario, the TCMT-TF tunnel goes all the way from one network edge 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 at the entry of 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 (which could be covered with specialized links) but from edge to edge (e.g. managing all traffic from individual users arriving at a Game Provider, regardless users' location). 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. +------+ N users -|TCM-IO|\ +------+ \ \ _ _ _ _ +------+ \--> ( ` )_ +------+ ( ` )_ M users -|TCM-IO|------> ( ) `) --|TCM-EO|--> ( ) `) +------+ / ->(_ (_ . _) _) +------+ (_ (_ . _) _) / +------+ / ISP Internet P users -|TCM-IO|/ +------+ <------------TCM-TF--------------> Figure 2 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 1, 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 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. Some examples: 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. [topology_CNs] Vega, D., Cerda-Alabern, L., Navarro, L., and R. Meseguer, "Topology patterns of a community network: Guifi. net.", Proceedings Wireless and Mobile Computing, Networking and Communications (WiMob), 2012 IEEE 8th International Conference on (pp. 612-619) , 2012. _______________________________________________ tcmtf mailing list tcmtf@ietf.org<mailto: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] TCM-TF: New Scenarios section Jose Saldana
- Re: [tcmtf] TCM-TF: New Scenarios section FERNANDO PASCUAL BLANCO
- Re: [tcmtf] TCM-TF: New Scenarios section Jose Saldana