Subject: Improved version (v8) of the TCM-TF charter draft

From: "Jose Saldana" <[email-masked]>
Date: Wed, 20 Nov 2013 12:13:59 +0100

TCM-TF charter draft v8

Description of Working Group

1. In the last years we are witnessing the raise of new real-time services
that use the Internet for the delivery of interactive multimedia
applications: VoIP, videoconferencing, telemedicine, video vigilance, online
gaming, etc. Due to the need of interactivity, many of these services use
small packets (some tens of bytes), since they have to send frequent updates
between the extremes of the communication. In addition, some other services
also send small packets, but they are not delay-sensitive (e.g., instant
messaging, m2m packets sending collected data in sensor networks using
wireless or satellite scenarios). For both the delay-sensitive and
delay-insensitive applications, their small data payloads incur significant
overhead, and it becomes even higher when IPv6 is used, since the basic IPv6
header is twice the size of the IPv4 one.

2. The efficiency cannot be increased by the inclusion of a higher number of
samples in a single packet, since this would harm the delay requirements of
the service. But there exist some scenarios in which a number of flows share
the same path. In this case, packets belonging to different flows can be
grouped together, adding a small multiplexing delay as a counterpart of
bandwidth saving. This delay will have to be maintained under some threshold
in order to grant the delay requirements. Some examples of the scenarios
where grouping packets is possible are:

- aggregation networks of a network operator;
- an end-to-end tunnel between appliances located in two different offices
of the same company;
- the access connection of an Internet Café including a high number of
VoIP/gaming flows;
- an agreement between two network operators could allow them to compress a
number of flows they are exchanging between a pair of Internet Routers;
- a wireless Internet connection shared by a number of people in a place
with low Internet penetration
- a community network, in which a number of people in the same geographical
place share their connections in a cooperative way
- a satellite connection used for collecting the data of a high number of
sensors.
- a satellite connection used for providing connectivity in a non-connected
area during a short period of time (e.g. journalists covering the arrival of
a mountain stage of a cycling competition).
- an air-to-ground connection providing Internet connectivity to the
passengers of an aircraft, multiplexing a number of simultaneous VoIP flows.
The same can be applied between a cruise ship and a satellite.

3. VoIP using RTP is a clear example of a real-time service using small
packets with high overhead. In order to improve efficiency, RFC4170 (TCRTP)
defined a method for grouping packets when a number of flows share a path,
considering three different layers: header compression by means of ECRTP;
multiplexing by means of PPPMux; tunneling by means of L2TPv3.

4. However, in the last years, emerging real-time services which do not use
UDP/RTP have become popular: some of them use UDP. In addition, new header
compression methods have been defined (ROHC). So there is a need of widening
the scope of RFC4170 in order to consider not only UDP/RTP but also other
protocols. The same structure of three layers will be considered:

- Header compression: Taking into account that real-time applications use
different headers (RTP/UDP, UDP), different protocols can be used: no
compression, ECRTP, IPHC and ROHC.
- Multiplexing: If a number of flows share a path between an origin and a
destination, a TCM-optimizer (called TCM-ingress optimizer) can build a
bigger multiplexed packet in which a number of payloads share a common
header. Another TCM-optimizer (called TCM-egress optimizer) is then
necessary at the end of the common path, so as to rebuild the packets as
they were originally sent. PPPMux will be the main option. Other ones are
not discarded.
- Tunneling will be used to send the multiplexed packets end-to-end. The
options in this layer are L2TP, GRE and MPLS.

5. So the first objective of this group is to specify the protocol stack for
tunneling, compressing and multiplexing traffic flows (TCM-TF). Since
standard protocols are being used at each layer, the signaling methods of
those protocols will be used. Interactions with the Working Groups and Areas
in which these protocols are developed can be expected. However, the
development of new compressing, multiplexing or tunneling protocols is not
an objective of this Working Group. In addition, since the current RFC 4170
would be considered as one of the options, this RFC could be obsoleted.

6. As a first objective, a document (TCM-TF - reference model) will define
the different options which can be used at each layer. Specific problems
caused by the interaction between layers will have to be issued, and
suitable extensions may have to be added to the involved protocols.

7. If a pair of ingress/egress optimizers want to establish a TCM-TF
session, they have first to use a mechanism to negotiate which concrete
option would they use in each layer: header compression, multiplexing and
tunneling. This will depend on the protocols that each extreme implements at
each level, and in the scenario. So another document (TCM-TF - negotiation
protocol) will include:

- a mechanism to setup/release a TCM-TF session between an ingress and an
egress-optimizer, also including:
- a negotiation mechanism to decide the options to use at each layer (header
compression, multiplexing and tunneling) between an ingress and an
egress-optimizer, 

8. As a counterpart of the bandwidth saving, TCM-TF may add some delay and
jitter. This is not a problem for the services which are not sensitive to
delay. However, regarding delay-sensitive services, the Working Group will
also develop a document (TCM-TF - recommendations) with useful
recommendations in order to decide which packet flows can or can not be
multiplexed and how. The document will present a list of available traffic
classification methods which can be used for identification of the service
or application to which a particular flow belongs, as well as
recommendations of the maximum delay and jitter to be added depending of the
identified service or application. The eventual impact of multiplexing on
protocol dynamics (e.g. the loss of a multiplexed packet, MTU-related
issues) will also have to be addressed.

9. The working group may identify additional deliverables that are
necessary/useful, e.g., a mechanism for a TCM-ingress optimizer to discover
an egress optimizer, and vice versa. The working group would re-charter to
add them before working on them.

10. In addition, specific uses of TCM-TF, such as in wireless and satellite
scenarios, could be considered, and it might be studied whether
modifications or extensions are required on the protocol. The working group
would re-charter to work on those modifications/extensions.

11. Interactions with other Working Groups can be expected, since TCM-TF
uses already defined protocols for compression, multiplexing and tunneling
(ROHC, PPPMux, MPLS, GRE, L2TP). 

Goals and Milestones

Specification of TCM-TF  reference model.

Specification of TCM-TF negotiation protocol.

Specification of TCM-TF recommendations of using existing traffic
classification methods, maximum delay and jitter to add, depending on the
service.

Current version of Document (TCM-TF - reference model):
https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/

Current version of Document (TCM-TF - recommendations):
http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

Best regards,

Jose

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 20 Nov 2013 18:40:48 +0000

Hi,

Some comments:

* Put somewhere more explicitly the problem statement. If we are doing
this to save bandwidth, then I suggest saying so in one bullet instead of
being lost inside a huge paragraph.
* Number 5: "So the first objective of this group². Then number 6 "As a
first objective, a document..². There are two first objectives with
different descriptions. Are these the same document or different documents?
* "The document will present a list of available traffic classification
methods which can be used for identification of the service or application
to which a particular flow belongs². My first reaction would be to not try
to list available classification methods since it will get into
implementation details. And what if traffic is e2e encrypted? Given the
whole surveillance thing should we we can expect this to happen? How would
you know a flow is candidate or suitable for compression?
* I wonder if some of the possible scenarios really apply. It seems we are
throwing everything to see what sticks.  Example: Journalist covering the
a cycling competition do not need write their report real time. And if
they need to do a interview, it seems to be working well right now, HD and
everything. 
* "- an agreement between two network operators could allow them to
compress a number of flows they are exchanging between a pair of Internet
Routers². Not sure compressing flows between peering routers is a good
use-case. 

On 11/20/13, 3:13 AM, "Jose Saldana" <[email-masked]> wrote:

>_______________________________________________
>tcmtf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tcmtf

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 21 Nov 2013 17:56:52 +0100

Hi, Reinaldo and Lars. Thank you very much for your comments. I will build a
new version of the charter in the next days.

Just a question about the scenarios. As agreed yesterday, we should limit to
scenarios with more than a single L3 hop. If there is a single L3 hop,
header compression (ROHC/ ECRTP / IPHC, depending on the protocols
implemented by the two optimizers) will suffice.

In some scenarios the number of hops is clear:
- in an air-to-ground connection there is a single hop. Not interesting for
TCM-TF
- in a pair of appliances creating a tunnel between two offices  of a
company, there are a number of hops. Interesting for TCM-TF

But what happens if a scenario may involve one, two or more L3 hops? This
will  happen in a "community network": you can create a tunnel just to
connect a village with the Internet (one hop), or to connect a village with
another village, which is the one really connected to the Internet (more
than one hop). See a paper about the topology of these networks here
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6379103.

Perhaps we should take this into account when thinking about the "TCM-TF
negotiation". Suppose there are two TCM-optimizers that want to create an
optimized tunnel. During the negotiation they SHOULD check if the number of
L3 hops between them is 1. In that case, they can avoid the tunnel, and also
the multiplexing (and multiplexing delay in turn). This could be seen as a
particular case of TCM-TF:

- Compression layer: ROHC
- Multiplexing layer: send every single packet. No need for PPPMux
- Tunneling layer: no tunnel

So perhaps we should also consider the "no multiplexing" and "no tunneling"
options in the protocol stack, in order to cover these cases.

What do you think?

Jose

> -----Mensaje original-----
> De: Reinaldo Penno (repenno) [mailto:[email-masked]]
> Enviado el: miércoles, 20 de noviembre de 2013 19:41
> Para: [email-masked]; [email-masked]; [email-masked]
> CC: Martin Stiemerling; 'Spencer Dawkins'
> Asunto: Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft
> 
> Hi,
> 
> Some comments:
> 
first
> objective, a document..². There are two first objectives with different
> descriptions. Are these the same document or different documents?
methods
> which can be used for identification of the service or application to
which a
> particular flow belongs². My first reaction would be to not try to list
> available classification methods since it will get into implementation
> details. And what if traffic is e2e encrypted? Given the whole
surveillance
> thing should we we can expect this to happen? How would you know a flow
> is candidate or suitable for compression?
a
> cycling competition do not need write their report real time. And if they
> need to do a interview, it seems to be working well right now, HD and
> everything.
> >1. In the last years we are witnessing the raise of new real-time
> >services that use the Internet for the delivery of interactive
> >multimedia
> >applications: VoIP, videoconferencing, telemedicine, video vigilance,
> >online gaming, etc. Due to the need of interactivity, many of these
> >services use small packets (some tens of bytes), since they have to
> >send frequent updates between the extremes of the communication. In
> >addition, some other services also send small packets, but they are not
> >delay-sensitive (e.g., instant messaging, m2m packets sending collected
> >data in sensor networks using wireless or satellite scenarios). For
> >both the delay-sensitive and delay-insensitive applications, their
> >small data payloads incur significant overhead, and it becomes even
> >higher when IPv6 is used, since the basic
> >IPv6
> >2. The efficiency cannot be increased by the inclusion of a higher
> >number of samples in a single packet, since this would harm the delay
> >requirements of the service. But there exist some scenarios in which a
> >number of flows share the same path. In this case, packets belonging to
> >different flows can be grouped together, adding a small multiplexing
> >delay as a counterpart of bandwidth saving. This delay will have to be
> >maintained under some threshold in order to grant the delay
> >requirements. Some examples of the scenarios where grouping packets is
> >possible are:
> >
> >- an end-to-end tunnel between appliances located in two different
> >offices of the same company;
> >- an agreement between two network operators could allow them to
> >compress a number of flows they are exchanging between a pair of
> >Internet Routers;
> >- a wireless Internet connection shared by a number of people in a
> >place with low Internet penetration
> >- a community network, in which a number of people in the same
> >geographical place share their connections in a cooperative way
> >- a satellite connection used for collecting the data of a high number
> >of sensors.
> >- a satellite connection used for providing connectivity in a
> >non-connected area during a short period of time (e.g. journalists
> >covering the arrival of a mountain stage of a cycling competition).
> >defined a method for grouping packets when a number of flows share a
> >path, considering three different layers: header compression by means
> >of ECRTP; multiplexing by means of PPPMux; tunneling by means of
> L2TPv3.
> >
> >4. However, in the last years, emerging real-time services which do not
> >use UDP/RTP have become popular: some of them use UDP. In addition,
> new
> >header compression methods have been defined (ROHC). So there is a
> need
> >of widening the scope of RFC4170 in order to consider not only UDP/RTP
> >but also other protocols. The same structure of three layers will be
> >considered:
> >
> >- Header compression: Taking into account that real-time applications
> >use different headers (RTP/UDP, UDP), different protocols can be used:
> >no compression, ECRTP, IPHC and ROHC.
> >- Multiplexing: If a number of flows share a path between an origin and
> >a destination, a TCM-optimizer (called TCM-ingress optimizer) can build
> >a bigger multiplexed packet in which a number of payloads share a
> >common header. Another TCM-optimizer (called TCM-egress optimizer) is
> >then necessary at the end of the common path, so as to rebuild the
> >packets as they were originally sent. PPPMux will be the main option.
> >Other ones are not discarded.
> >- Tunneling will be used to send the multiplexed packets end-to-end.
> >The options in this layer are L2TP, GRE and MPLS.
> >
> >5. So the first objective of this group is to specify the protocol
> >stack for tunneling, compressing and multiplexing traffic flows
> >(TCM-TF). Since standard protocols are being used at each layer, the
> >signaling methods of those protocols will be used. Interactions with
> >the Working Groups and Areas in which these protocols are developed can
> >be expected. However, the development of new compressing,
> multiplexing
> >or tunneling protocols is not an objective of this Working Group. In
> >addition, since the current RFC
> >4170
> >6. As a first objective, a document (TCM-TF - reference model) will
> >define the different options which can be used at each layer. Specific
> >problems caused by the interaction between layers will have to be
> >issued, and suitable extensions may have to be added to the involved
> protocols.
> >
> >option would they use in each layer: header compression, multiplexing
> >and tunneling. This will depend on the protocols that each extreme
> >implements at each level, and in the scenario. So another document
> >(TCM-TF - negotiation
> >protocol) will include:
> >
> >- a mechanism to setup/release a TCM-TF session between an ingress and
> >an egress-optimizer, also including:
> >- a negotiation mechanism to decide the options to use at each layer
> >(header compression, multiplexing and tunneling) between an ingress and
> >an egress-optimizer,
> >
> >8. As a counterpart of the bandwidth saving, TCM-TF may add some delay
> >and jitter. This is not a problem for the services which are not
> >sensitive to delay. However, regarding delay-sensitive services, the
> >Working Group will also develop a document (TCM-TF - recommendations)
> >with useful recommendations in order to decide which packet flows can
> >or can not be multiplexed and how. The document will present a list of
> >available traffic classification methods which can be used for
> >identification of the service or application to which a particular flow
> >belongs, as well as recommendations of the maximum delay and jitter to
> >be added depending of the identified service or application. The
> >eventual impact of multiplexing on protocol dynamics (e.g. the loss of
> >a multiplexed packet, MTU-related
> >necessary/useful, e.g., a mechanism for a TCM-ingress optimizer to
> >discover an egress optimizer, and vice versa. The working group would
> >re-charter to add them before working on them.
> >
> >10. In addition, specific uses of TCM-TF, such as in wireless and
> >satellite scenarios, could be considered, and it might be studied
> >whether modifications or extensions are required on the protocol. The
> >working group would re-charter to work on those
> >modifications/extensions.
> >
> >11. Interactions with other Working Groups can be expected, since
> >TCM-TF uses already defined protocols for compression, multiplexing and
> >tunneling (ROHC, PPPMux, MPLS, GRE, L2TP).
> >
> >
> >Goals and Milestones
> >
> >classification methods, maximum delay and jitter to add, depending on
> >the service.
> >
> >

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 21 Nov 2013 17:09:14 +0000

Hi,

> company, there are a number of hops. Interesting for TCM-TF

there are multiple hops, but are there pressing resource constraints? The intranet in all companies I have worked for has worked well enough without TCM-TF. If you lease MPLS circuits, you can easily acquire more bandwidth.

> http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6379103.

All of these PEPs really only make sense on the resource-constrained hop. In your village example, put them on each side of the congested link. Then it's a one-hop scenario. There is little point in going through the overheads of compressing, tunneling, etc. when there is ample resource capacity.

> options in the protocol stack, in order to cover these cases.

The point I'm trying to make is that I haven't seen *any* scenario that requires a multi-hop solution. And therefore to me what we have with ROHC seems to be just fine.

Lars

---

From: "Jose Saldana" <[email-masked]>
Date: Fri, 22 Nov 2013 10:50:08 +0100

Hi, Lars.

During the BoF in Berlin, I got the impression that the problem was not the
idea of TCM-TF itself, but some of the considered options (e.g. TCP). There
were many people who raised their hands when asked about "willing to review
docs or comment on mailing list". However, it seems that there are some
people who are not convinced about the utility of TCM-TF. 

So in order to reach consensus, let us keep on discussing and thinking. This
is very enriching, since it is making us refine the scenarios where TCM-TF
may have a real potential, and discard the ones in which it makes no sense.

I have added two comments inline:

> De: Eggert, Lars [mailto:[email-masked]]
> Enviado el: jueves, 21 de noviembre de 2013 18:09
> 
> Hi,
> 
> there are multiple hops, but are there pressing resource constraints? The
> intranet in all companies I have worked for has worked well enough without
> TCM-TF. If you lease MPLS circuits, you can easily acquire more bandwidth.
> 
> > But what happens if a scenario may involve one, two or more L3 hops?
> > This will  happen in a "community network": you can create a tunnel
> > just to connect a village with the Internet (one hop), or to connect a
> > village with another village, which is the one really connected to the
> > Internet (more than one hop). See a paper about the topology of these
> > networks here
> All of these PEPs really only make sense on the resource-constrained hop.
> In your village example, put them on each side of the congested link. Then
> it's a one-hop scenario. There is little point in going through the
overheads
> of compressing, tunneling, etc. when there is ample resource capacity.

This is a very interesting point: we cannot assume that we will have ample
resource capacity everywhere and always. There are situations in which a
traffic rush occurs, and in these situations there are a number of congested
links. I am not only thinking on emerging countries, but also in a traffic
rush anywhere.

What I mean is that we cannot think we have ample resources everywhere and
always. 
- Everywhere: The user mobility makes it difficult to predict bandwidth
scarcity problems in some places.
- Always: A traffic rush may appear at a certain moment (e.g. the release of
a new game).

The idea is that TCM-TF is dormant, and it only gets activated when network
capacity becomes scarce. As Dan said in the BoF, TCM-TF provides a degree of
flexibility: you can exchange processing power and bandwidth when required.
In these situations, when a traffic rush occurs, why not activating TCM
optimization, and reducing the amount of pps and the bandwidth requirements
by optimizing the small-packet flows? Network operators have to transport
lots of small-packet flows, and this is not efficient (even in terms of
energy consumption, since header processing accounts for the majority of the
power requirements of a router).

Regarding the village example: community networks are really challenging
scenarios where VoIP and real-time services have a lot of problems to work
properly, so perhaps traffic optimization can be needed frequently (e.g. in
the afternoon when everyone is trying to use skype at home).

> > Perhaps we should take this into account when thinking about the
> > "TCM-TF negotiation". Suppose there are two TCM-optimizers that want
> > to create an optimized tunnel. During the negotiation they SHOULD
> > check if the number of
> > L3 hops between them is 1. In that case, they can avoid the tunnel,
> > and also the multiplexing (and multiplexing delay in turn). This could
> > be seen as a particular case of TCM-TF:
> >
> The point I'm trying to make is that I haven't seen *any* scenario that
> requires a multi-hop solution. And therefore to me what we have with
> ROHC seems to be just fine.
> 
> Lars

Should we then update RFC4170 so as to consider ROHC instead of ECRTP? We
cannot forget that the idea of TCM-TF is to update and to broaden the scope
of RFC4170.

Thanks a lot!

Jose

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 22 Nov 2013 15:41:50 +0000

Hi,

> links. I am not only thinking on emerging countries, but also in a traffic

I'm with you so far.

> capacity becomes scarce.

Here is where I start to disagree. I don't buy the idea that we should be deploying TCM-TF boxes everywhere that get activated when capacity is scarce. I believe in simply adding more capacity where needed when needed. And even when doing the deployment on-demand, why would we not instead simply deploy more bandwidth?

Yes, in specific cases that is not possible, such as when you are running out of capacity on a wireless hop of some sort where you can't get more spectrum. But I believe we have sufficient mechanisms available for these cases.

> As Dan said in the BoF, TCM-TF provides a degree of

But first you need to deploy that processing power. When you have the choice of deploying processing power or deploying capacity, why wouldn't you deploy capacity?

> by optimizing the small-packet flows?

Because the TCM optimization is not free. You need to deploy if before you can use it. I fundamentally believe in deploying bandwidth instead of deploying boxes that manage bandwidth scarcity.

And yes, in some scenarios PEPs make sense, but as I said above, I don't think we're lacking any technology in this space.

> Network operators have to transport

Citation please?

Also, if we're talking energy, you need to account for he processing that TCM requires.

> the afternoon when everyone is trying to use skype at home).

OK, I'll bite. Have you looked at the size of packets that Skype uses? They are not small.

Lars

---

From: "Jose Saldana" <[email-masked]>
Date: Fri, 22 Nov 2013 17:35:31 +0100

Hi, Lars.

Just the required citations about energy in routers, and about skype:

[1]  R. Bolla, R. Bruschi, F. Davoli,  F .Cucchietti, "Energy Efficiency in
the Future Internet: A Survey of Existing Approaches and Trends in
Energy-Aware Fixed Network Infrastructures", Communications Surveys &
Tutorials, IEEE, vol.13, no.2, pp.223,244, Second Quarter 2011.

[2] J. Chabarek, J. Sommers, P. Barford, C. Estan, D. Tsiang, S. Wright,
"Power Awareness in Network Design and Routing", INFOCOM 2008. The 27th
Conference on Computer Communications. IEEE , vol., no., pp.457,465, 13-18
Apr. 2008

According to [1] internal packet processing engines and switching fabric
require 60% and 18% of the power consumption of high-end routers
respectively. Thus, reducing the number of packets to be managed and
switched will reduce the overall energy consumption.

The measurements deployed in [2] on commercial routers corroborate this: a
study using different packet sizes was presented, and the tests with big
packets made the energy consumption get reduced, since a certain amount of
energy is associated to header processing tasks, and not only to the sending
of the packet itself.

Obviously, as you say, we should also measure the tradeoff:

a) energy consumption is increased in the two extremes (mux-demux)
b) energy consumption is reduced in the intermediate nodes

The two references only talk about b), so the tradeoff should be explored
more deeply.

Regarding Skype, I have just run a test with the echo tool and captured with
Wireshark. If the video is disabled, the packet size (only UDP packets) is
roughly 100 data bytes + headers.

Uplink 153 bytes average
Downlink 149 bytes

[3] Bonfiglio, D., Mellia, M., Meo, M., Ritacca, N., & Rossi, D. (2008,
April). Tracking down skype traffic. In INFOCOM 2008. The 27th Conference on
Computer Communications. IEEE (pp. 261-265). 

[4] Rossi, D., Mellia, M., & Meo, M.. A detailed measurement of skype
network traffic. In IPTPS (p. 12), Feb. 2008.

This is valid if you only use Voice. If you activate video, packets become
larger, as you say. I should have specified this. Sorry.

Best regards,

Jose

> De: tcmtf [mailto:[email-masked]] En nombre de Eggert, Lars
> Enviado el: viernes, 22 de noviembre de 2013 16:42
> Para: [email-masked]
> CC: [email-masked]; [email-masked]; Martin Stiemerling; Reinaldo Penno
> (repenno); Spencer Dawkins
> > This is a very interesting point: we cannot assume that we will have
> > ample resource capacity everywhere and always. There are situations in
> > which a traffic rush occurs, and in these situations there are a
> > number of congested links. I am not only thinking on emerging
> > countries, but also in a traffic rush anywhere.
> 
> I'm with you so far.
> 
> > The idea is that TCM-TF is dormant, and it only gets activated when
> > network capacity becomes scarce.
> 
> Here is where I start to disagree. I don't buy the idea that we should be
> deploying TCM-TF boxes everywhere that get activated when capacity is
> scarce. I believe in simply adding more capacity where needed when
> needed. And even when doing the deployment on-demand, why would we
> not instead simply deploy more bandwidth?
> 
> Yes, in specific cases that is not possible, such as when you are running
out
> of capacity on a wireless hop of some sort where you can't get more
> spectrum. But I believe we have sufficient mechanisms available for these
> cases.
> 
> But first you need to deploy that processing power. When you have the
> choice of deploying processing power or deploying capacity, why wouldn't
> you deploy capacity?
> 
> > In these situations, when a traffic rush occurs, why not activating
> > TCM optimization, and reducing the amount of pps and the bandwidth
> > requirements by optimizing the small-packet flows?
> 
> Because the TCM optimization is not free. You need to deploy if before you
> can use it. I fundamentally believe in deploying bandwidth instead of
> deploying boxes that manage bandwidth scarcity.
> 
> And yes, in some scenarios PEPs make sense, but as I said above, I don't
> think we're lacking any technology in this space.
> 
> > lots of small-packet flows, and this is not efficient (even in terms
> > of energy consumption, since header processing accounts for the
> > majority of the power requirements of a router).
> 
> Citation please?
> 
> > Regarding the village example: community networks are really
> > challenging scenarios where VoIP and real-time services have a lot of
> > problems to work properly, so perhaps traffic optimization can be
> > needed frequently (e.g. in the afternoon when everyone is trying to use
> skype at home).
> 
> OK, I'll bite. Have you looked at the size of packets that Skype uses?
They
> are not small.

---

From: "Jose Saldana" <[email-masked]>
Date: Mon, 25 Nov 2013 09:44:33 +0100

Hi, Tim.

I think it is a good idea and we should definitely explain the scenarios in
more detail.

When you talk about a "deliverable which describes scenarios and
requirements," do you mean another draft? In the current "TCM-TF reference
model" draft, section 1.4 is about "Scenarios of application". Would it be
enough if we improve that section according to what we have discussed in the
last days?

http://tools.ietf.org/html/draft-saldana-tsvwg-tcmtf-05#section-1.4

Regarding the potential effects on other protocols, do you think we should
include that on the same draft?

Thanks a lot,

Jose

> De: Tim Chown [mailto:[email-masked]]
> Enviado el: sábado, 23 de noviembre de 2013 10:58
> Para: [email-masked]
> CC: Eggert, Lars; [email-masked]; [email-masked]; Martin Stiemerling;
> Reinaldo Penno (repenno); Spencer Dawkins
> On 22 Nov 2013, at 09:50, Jose Saldana <[email-masked]> wrote:
> 
> > Hi, Lars.
> >
> > During the BoF in Berlin, I got the impression that the problem was
> > not the idea of TCM-TF itself, but some of the considered options
> > (e.g. TCP). There were many people who raised their hands when asked
> > about "willing to review docs or comment on mailing list". However, it
> > seems that there are some people who are not convinced about the utility
> of TCM-TF.
> >
> > So in order to reach consensus, let us keep on discussing and
> > thinking. This is very enriching, since it is making us refine the
> > scenarios where TCM-TF may have a real potential, and discard the ones
in
> which it makes no sense.
> 
> I think it may be useful if the charter includes a deliverable which
describes
> scenarios and requirements. At present, the scenarios and existing
> solutions are presented in points 1-4 of the charter, rather than being
more
> formally documented as part of the WG activities. Such a document could
> explain why, from a requirements perspective, ROHC isn’t sufficient for
the
> use cases envisioned. It could also clarify what’s in scope, e.g. point 2
> mentions satellite while point 10 mentions satellite as possible future
> work. There’s been some good scenario discussion on the list recently
> which could all be captured.
> 
> What’s also missing is analysis of the impact on other protocols of
deploying
> soemthing like this; this concern was raised at the previous BoF.
> 
> Tim

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 27 Nov 2013 12:58:34 +0100

Hi, Reinaldo. 

> Asunto: Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft
(...) 
methods
which a
surveillance
> is candidate or suitable for compression?

One question about this. Our idea is to list some possibilities to be used
for a TCM optimizer in order to select the flows to optimize. Some examples:

- DPI. However, some people would say that it is against network neutrality,
and it may also be difficult if the flow is encrypted.

- Selecting according to IPs and port numbers. For example, if a flow has a
destination IP belonging to a game company, it is a clear candidate. This
would be possible if there is an agreement between the ISP and the game
company.

- The packets include specific diffserv values.

- Automatic detection based on statistics of Inter-packet time and packet
size have also been proposed. They are not against neutrality:
T. T. Nguyen, G. Armitage, P. Branch, S. Zander, “Timely and continuous
machine-learning-based classification for interactive IP traffic,” IEEE/ACM
Trans. on Networking, 20(6), pp 1880-1894, 2012.

What do you think about these possibilities?

Thanks,

Jose

a

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 27 Nov 2013 16:23:32 +0000

HI Jose,

None of my objections in this case are purely technical. The problem with
these solution is that although technical feasible, it leaves out the one
person that should have some saying on which traffic gets compressed or
not: the user.

I really do not expect users configuring access lists so that traffic from
a certain port eta compressed. Or trusting a DPI with some pre‹configured
policies that could be hit and miss. It would be good if user or app could
have a way to convey preference of which app should be compressed.

This brings me to an interesting point:

Let¹s suppose XBOX gaming traffic compressed and bandwidth is reduced by
20%. Netflix detects there is much more bandwidth and TCP opens its window
to engulf that new 20% available.  You are mostly back to where you were.
So, if you go throughout the trouble of compressing some traffic, would
that need to be couple with some protection?

On 11/27/13, 3:58 AM, "Jose Saldana" <[email-masked]> wrote:

>T. T. Nguyen, G. Armitage, P. Branch, S. Zander, ³Timely and continuous
>machine-learning-based classification for interactive IP traffic,²
>IEEE/ACM

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 28 Nov 2013 09:58:39 +0100

Hi, Tim.  I don't know if I understood well what you are proposing. Please
check the new text and tell me if it is what you meant.

Thanks a lot!

Jose

> Enviado el: miércoles, 27 de noviembre de 2013 15:58
> Para: [email-masked]
> CC: [email-masked]; [email-masked]; 'Martin Stiemerling'; 'Spencer
> Dawkins'
> Hi Jose,
> On 25 Nov 2013, at 08:44, Jose Saldana <[email-masked]> wrote:
> 
> > Hi, Tim.
> >
> > I think it is a good idea and we should definitely explain the
> > scenarios in more detail.
> >
> > requirements," do you mean another draft? In the current "TCM-TF
> > reference model" draft, section 1.4 is about "Scenarios of
> > application". Would it be enough if we improve that section according
> > to what we have discussed in the last days?
> >
> > Regarding the potential effects on other protocols, do you think we
> > should include that on the same draft?
> 
> I think the text now in the reference model v9 in point 8 covers the
> comment about scenarios.  It could be a separate draft, it could be the
same
> draft.
OK!

> I'm not sure it addresses the issue of the impact on other protocols. This
> may be an axis on the design space?  And then to at least document the
> impact on other protocols of adopting the proposed combination of
> mechanisms at the three layers to be described in the reference model.
> Examples of these issues were raised at the IETF87 BoF, and may come up
> again in a future BoF if the charter doesn't include consideration of
them.
Regarding the impact on other protocols, the current version of the Charter
says:

8. A first document (TCM-TF - reference model) will define the different
options which can be used at each layer. It will include a detailed
specification of the scenarios of interest. Specific problems caused by the
interaction between layers will have to be issued, and suitable extensions
may have to be added to the involved protocols. The impact on other
protocols will also be studied.

10. (...) The eventual impact of multiplexing on protocol dynamics (e.g. the
loss of a multiplexed packet, MTU-related issues) will also have to be
addressed.

So what you are proposing (if understood well) is something like this?:

The eventual impact of the combination of mechanisms proposed by TCM-TF on
the dynamics of already existing protocols will be studied and documented on
the TCM-TF- reference model. This is a (non-exhaustive) list of possible
interactions:

* Packet loss: The loss of a multiplexed packet may imply a number of
simultaneous packet losses affecting different flows. This may affect ...

* MTU: When multiplexing a number of packets, the packet size gets
increased, and this may produce some issues related to the Maximum Transfer
Unit of a network.

* more ideas?

> Will the reference model summarise the requirements, as distilled from the
> scenarios that are deemed to be in scope?

The requirements, in terms of maximum delay, etc., would be summarised in
the "TCM-TF recommendations" document.
> >> De: Tim Chown [mailto:[email-masked]] Enviado el: sábado, 23 de
> >> noviembre de 2013 10:58
> >> Para: [email-masked]
> >> CC: Eggert, Lars; [email-masked]; [email-masked]; Martin
> >> Stiemerling; Reinaldo Penno (repenno); Spencer Dawkins
> >>> about "willing to review docs or comment on mailing list". However,
> >>> it seems that there are some people who are not convinced about the
> >>> utility
> >> of TCM-TF.
> >>>
> >> formally documented as part of the WG activities. Such a document
> >> could explain why, from a requirements perspective, ROHC isn’t
> >> sufficient for
> > the
> >> use cases envisioned. It could also clarify what’s in scope, e.g.
> >> point 2 mentions satellite while point 10 mentions satellite as
> >> possible future work. There’s been some good scenario discussion on
> >> the list recently which could all be captured.
> >>

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 28 Nov 2013 10:08:30 +0100

Hi, Reinaldo. This is an interesting point.

My idea is that TCM-TF only makes sense when a number of flows share a
bottleneck and its bandwidth gets scarce. So it is not a problem of a user
but a problem of the network. The end user (or the X-Box) in this case would
only perceive an additional (limited) delay and jitter, but this is
something that is done deeply in the network, when links get congested. And
sometimes network operators have different connections for best-effort and
for online game traffic. So if the online games connection gets clogged at a
certain point or moment, TCM-TF would then activate only there.

The network operator is the one who has to grant the user a good connection
when he is playing. This includes:

1- Always working in an acceptable way
2- Low delay, jitter and packet loss

When (1) becomes difficult because of congestion, you may optimize the
traffic (sacrifice a bit of (2) in order to maintain (1).

Was this your idea?

Jose

> De: tcmtf [mailto:[email-masked]] En nombre de Reinaldo Penno
> (repenno)
> Enviado el: miércoles, 27 de noviembre de 2013 17:24
> CC: 'Martin Stiemerling'; 'Spencer Dawkins'
a
> certain port eta compressed. Or trusting a DPI with some pre‹configured
> 20%. Netflix detects there is much more bandwidth and TCP opens its
> window to engulf that new 20% available.  You are mostly back to where
> you were.
that
> need to be couple with some protection?
> 
> 
> >One question about this. Our idea is to list some possibilities to be
> >used for a TCM optimizer in order to select the flows to optimize. Some
> >examples:
> >
> >- DPI. However, some people would say that it is against network
> >neutrality, and it may also be difficult if the flow is encrypted.
> >
> >- Selecting according to IPs and port numbers. For example, if a flow
> >has a destination IP belonging to a game company, it is a clear
> >candidate. This would be possible if there is an agreement between the
> >ISP and the game company.
> >
> >- Automatic detection based on statistics of Inter-packet time and
> >packet size have also been proposed. They are not against neutrality:
> >IEEE/ACM Trans. on Networking, 20(6), pp 1880-1894, 2012.
> >

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 28 Nov 2013 10:53:08 +0000

Hi,

> that need to be couple with some protection?

this is a key point.

WAN acceleration works, because all traffic goes through the tunnel, and the tunnel endpoints prioritize flows. Well, and because they basically disable congestion control, so they can grab max bandwidth for the tunnel.

If you only tunnel some of the packets and let others flow past the tunnel, you have the issue Reinaldo raises. Even if you tunnel everything, unless you use aggressive non-IETF-standardized congestion control for the tunnel, other cross traffic can steal the bandwidth you just freed up by compressing.

Lars

---

From: "Jose Saldana" <[email-masked]>
Date: Fri, 29 Nov 2013 11:15:14 +0100

Hi. I am not sure I understand the problem. Let's use two examples.

a) You have a bottleneck of 1 Mbps, and the offered traffic is:

- UDP 1.1 Mbps
- TCP. It will take as much as it can, using its mechanisms.

In this case, UDP flows will have a lot of delay and packet loss, since they
do not react against congestion. TCP flows will get nothing, since there is
no place for them.

If we use ROHC (for a single hop) or TCM-TF (for more than a hop) and
compress UDP flows to (let's say) 800 kbps, then we will have:

- UDP 800 kbps
- TCP will take the other 200 kbps

b) You have a bottleneck of 1 Mbps, and the offered traffic is:

- UDP 700 kbps
- TCP: It will take the other 300 kbps.

In this case, if we compress UDP to 500 kbps, then TCP will take 500 kbps
instead of 300 kbps.

TCP always takes the bandwidth that UDP leaves. So if you compress UDP, TCP
will have more bandwidth. (I am talking about TCP for FTP or for downloading
a movie. If we talk about TCP for an MMORPG game, the story will be
different)

What do you think?

Jose

> Enviado el: jueves, 28 de noviembre de 2013 11:53
> Para: Reinaldo Penno (repenno)
> CC: [email-masked]; Martin Stiemerling; [email-masked];
> [email-masked]
> > Let¹s suppose XBOX gaming traffic compressed and bandwidth is reduced
> > by 20%. Netflix detects there is much more bandwidth and TCP opens its
> > So, if you go throughout the trouble of compressing some traffic,
> > would that need to be couple with some protection?
> 
> this is a key point.
> 
> WAN acceleration works, because all traffic goes through the tunnel, and
> the tunnel endpoints prioritize flows. Well, and because they basically
> disable congestion control, so they can grab max bandwidth for the tunnel.
> 
> If you only tunnel some of the packets and let others flow past the
tunnel,
> you have the issue Reinaldo raises. Even if you tunnel everything, unless
> you use aggressive non-IETF-standardized congestion control for the
tunnel,
> other cross traffic can steal the bandwidth you just freed up by
compressing.