Subject: [tcmtf] Scenarios or Use Cases?

From: Alexander Harrowell <[email-masked]>
Date: Wed, 5 Mar 2014 13:08:51 +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: "Jose Saldana" <[email-masked]>
Date: Wed, 5 Mar 2014 20:41:11 -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:[email-masked]] En nombre de Alexander
> Harrowell
> Enviado el: miércoles, 05 de marzo de 2014 13:09
> Para: [email-masked]
> 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.
> 
> 
> 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.
> _ _ _ _ _ _
> ( ' ) _ _ _ ( ' )_ _
> ( +------+ _) (_ (_ . _) _) ( +------+ _) (_ _ _ _) (_ _ ( _) _) 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).
> 
> 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.
> 
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.
> At the same time, the ISP would implement TCM-TF capabilities within its
> own MPLS network in order to optimize internal network resources:
> 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.
> 
> 
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
> 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
> 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.
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
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
> 
> 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 \
> _ _ \ _ _ _ _ _
> _______________________________________________
> tcmtf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcmtf