Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft

["Jose Saldana" <[e-mail]>]

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:[e-mail]]
> Enviado el: jueves, 21 de noviembre de 2013 18:09
> 
> Hi,
> 
> On 2013-11-21, at 11:56, Jose Saldana <[e-mail]> wrote:
> > - in a pair of appliances creating a tunnel between two offices  of a
> > 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.
> 
> > 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.
> 
> 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:
> >
> > - 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.
> 
> 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