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