Re: [tcmtf] Scenarios or Use Cases?
"Jose Saldana" <jsaldana@unizar.es> Wed, 05 March 2014 20:41 UTC
Return-Path: <jsaldana@unizar.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 0C9F81A0290 for <tcmtf@ietfa.amsl.com>; 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 <tcmtf@ietfa.amsl.com>; 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 <tcmtf@ietf.org>; 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 <jsaldana@unizar.es>
To: 'Alexander Harrowell' <a.harrowell@gmail.com>, tcmtf@ietf.org
References: <CA+qGm=8NKTGKa5XwQ8aiGFnhNmBwgLGu3py8o_a2X+djxU6-rw@mail.gmail.com>
In-Reply-To: <CA+qGm=8NKTGKa5XwQ8aiGFnhNmBwgLGu3py8o_a2X+djxU6-rw@mail.gmail.com>
Date: Wed, 05 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" <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, 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Ʃrcoles, 05 de marzo de 2014 13:09 > Para: tcmtf@ietf.org > Asunto: [tcmtf] Scenarios or Use Cases? > > 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 > > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf
- [tcmtf] Scenarios or Use Cases? Alexander Harrowell
- Re: [tcmtf] Scenarios or Use Cases? Jose Saldana