Subject: TCM-TF: New Scenarios section

From: "Jose Saldana" <[email-masked]>
Date: Tue, 3 Dec 2013 12:28:20 +0100

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.

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Wed, 11 Dec 2013 17:00:33 +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
[email-masked]<mailto:[email-masked]> |F +34 91 312 8779  |  M +34 682 005 168

On 03/12/2013, at 12:28, Jose Saldana <[email-masked]<mailto:[email-masked]>> 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.

Thanks a lot!

Jose

   domain.

      _  _                       _  _                       _  _

        ISP 1                     Internet                   ISP 2

                                 Figure 1

   users' location).

1.4.2.  Single domain

   conditions.

            +------+

   N users -|TCM-IO|\

            +------+ \

                      \       _  _                        _  _

                      /

            +------+ /         ISP                        Internet

   P users -|TCM-IO|/

            +------+

                                 Figure 2

   network

1.4.3.  Private solutions

      _  _                       _  _                       _  _

                                 Figure 3

      viability.

      efficiency.

1.4.4.  Mixed scenarios

      savings for both actors.

_______________________________________________
tcmtf mailing list
[email-masked]<mailto:[email-masked]>
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

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 12 Dec 2013 16:26:48 +0100

Thank you, Fernando.

I think your scenario can be a perfect example for a “mixed” one. So I will
include it as an example in 1.4.4. I will have to modify the (very good)
drawing a bit, because it is too wide!

Thanks a lot!

Jose

De: tcmtf [mailto:[email-masked]] En nombre de FERNANDO PASCUAL
BLANCO
Enviado el: miércoles, 11 de diciembre de 2013 18:01
Para: Jose Saldana
CC: [email-masked]; Martin Stiemerling; [email-masked]; Spencer Dawkins
Asunto: Re: [tcmtf] TCM-TF: New Scenarios section

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:

                              _  _        
                             ( `   )_    
           +---------+      (    )    `)      

           +---------+          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

 <mailto:[email-masked]> [email-masked] |F +34 91 312
8779  |  M +34 682 005 168

On 03/12/2013, at 12:28, Jose Saldana <[email-masked]> 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.

Thanks a lot!

Jose

 

      _  _                       _  _                       _  _
 
        ISP 1                     Internet                   ISP 2

                                 Figure 1

1.4.2.  Single domain

            +------+
   N users -|TCM-IO|\
            +------+ \
                      \       _  _                        _  _

                                 Figure 2

 
 
1.4.3.  Private solutions

      _  _                       _  _                       _  _

 
                                 Figure 3

 

 

1.4.4.  Mixed scenarios

 

_______________________________________________
tcmtf mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/tcmtf>
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