Re: [tcmtf] Improvements in the TCM-TF charter draft v8

"Jose Saldana" <> Wed, 20 November 2013 15:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A3AD21AE012; Wed, 20 Nov 2013 07:25:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.726
X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t1N4Xqs8yXOZ; Wed, 20 Nov 2013 07:25:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3AD121ADFF0; Wed, 20 Nov 2013 07:25:04 -0800 (PST)
Received: from usuarioPC ( []) by (8.13.8/8.13.8/Debian-3) with ESMTP id rAKFOpED030900; Wed, 20 Nov 2013 16:24:52 +0100
From: "Jose Saldana" <>
To: "'Eggert, Lars'" <>
References: <008b01cee5e1$93b2e460$bb18ad20$> <>
In-Reply-To: <>
Date: Wed, 20 Nov 2013 16:24:56 +0100
Organization: Universidad de Zaragoza
Message-ID: <002801cee604$abcb7b20$03627160$>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Content-language: es
Thread-index: AQG+D5B7Uz/tXBkoaMTv40ANCKbK9AHmFa++mkC4SrA=
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Cc:, 'Martin Stiemerling' <>,
Subject: Re: [tcmtf] Improvements in the TCM-TF charter draft v8
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Tunneling Compressed Multiplexed Traffic Flows \(TCMTF\) discussion list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Nov 2013 15:25:06 -0000

Hi, Lars.

ROHC in fact is the most important part of the solution, since it is the
algorithm that reduces the size of the headers dramatically. Since the
header and the payload are in the same order of magnitude, the saving is
significant. ROHC can be enough if you are considering a single hop.

But if you want to use it in more than a single hop, ROHC has to be
tunneled, and you lose the savings achieved by compression. So the idea is
that a number of packets (multiplexed) share the tunnel overhead.

Best regards,


-----Mensaje original-----
De: tcmtf [] En nombre de Eggert, Lars
Enviado el: miércoles, 20 de noviembre de 2013 15:04
CC:; Martin Stiemerling;
Asunto: Re: [tcmtf] Improvements in the TCM-TF charter draft v8


why is ROHC not a solution?


On 2013-11-20, at 6:13, Jose Saldana <>; wrote:

> Hi all.
> We have the idea of asking for a BoF in London in March 2014. For this 
> aim, we should discuss a new version of the charter draft. I send it 
> in the next e-mail.
> This e-mail summarizes the improvements. I have put different numbers, 
> in order to discuss them separately in the list.
> 1- In order to be consistent with the drafts, the charter should talk 
> about "TCM-ingress and egress optimizers" instead of "TCM multiplexers 
> and demultiplexers".
> 2- A new scenario has been included "a wireless Internet connection 
> shared by a number of people in a place with low Internet 
> penetration", taking into account that some people from Africa were 
> interested on TCM for improving real-time applications in this kind of
> 3- Scenario: "a community network, in which a number of people in the 
> same geographical place share their connections in a cooperative way". 
> It has some similarities with the previous one.
> 4- Scenario: "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
> 5- Scenario: " -	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."
> 6- According to the feedback received in the BoF in Berlin, the 
> references to TCP have been removed.
> 7- A reference to the potential problem of the MTU and packet loss has 
> been added in number 8: "The eventual impact of multiplexing on 
> protocol dynamics (e.g. the lost of a multiplexed packet, MTU-related 
> issues) will also have to be addressed.."
> Any other suggestions, according to what we discussed in the BoF?
> Best regards,
> Jose Saldana