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

[Julián Fernández-Navajas <[e-mail]>]

Hi, all.
I have followed the thread with the discussion about TCM-TF utility. My 
point of view is that many of the multimedia apps developers have 
learned that the traffic of little packets are penalized at Internet. 
So, usually, the apps adds all the information possible in the building 
of the packets. They apply multiplexion end to end. But in many 
situation is necessary to send the different information (audio, video, 
text ...) in differents packets by the network in order to obtain the 
suitable QoS. At this situations is very useful TCM-TF.
Julián

El 22/11/2013 10:50, Jose Saldana escribió:
> 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
>
> _______________________________________________
> tcmtf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcmtf
>