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

"Eggert, Lars" <> Thu, 21 November 2013 17:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2DAEA1AE004; Thu, 21 Nov 2013 09:09:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.427
X-Spam-Status: No, score=-7.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FtXxuw1-dx_c; Thu, 21 Nov 2013 09:09:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1E4271ADF70; Thu, 21 Nov 2013 09:09:24 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.93,745,1378882800"; d="asc'?scan'208"; a="118360709"
Received: from ([]) by with ESMTP; 21 Nov 2013 09:09:16 -0800
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Thu, 21 Nov 2013 09:09:16 -0800
From: "Eggert, Lars" <>
To: "" <>
Thread-Topic: [tcmtf] Improved version (v8) of the TCM-TF charter draft
Thread-Index: Ac7l26JNd/G0n/QzTnmgW1GPEao+ugAM6JKAAEOdowAAAG6RAA==
Date: Thu, 21 Nov 2013 17:09:14 +0000
Message-ID: <>
References: <008c01cee5e1$9caa4590$d5fed0b0$> <> <01ee01cee6da$b05eb9a0$111c2ce0$>
In-Reply-To: <01ee01cee6da$b05eb9a0$111c2ce0$>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_8FB752B8-6498-4938-B1F0-D39A294D04E4"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Cc: "" <>, "" <>, Martin Stiemerling <>, "Reinaldo Penno \(repenno\)" <>, Spencer Dawkins <>
Subject: Re: [tcmtf] Improved version (v8) of the TCM-TF charter draft
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: Thu, 21 Nov 2013 17:09:26 -0000


On 2013-11-21, at 11:56, Jose Saldana <> 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

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.

> 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.