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

"Eggert, Lars" <lars@netapp.com> Wed, 20 November 2013 17:19 UTC

Return-Path: <lars@netapp.com>
X-Original-To: tcmtf@ietfa.amsl.com
Delivered-To: tcmtf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCA91AE0C6; Wed, 20 Nov 2013 09:19:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level:
X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJzTJpxzPCDx; Wed, 20 Nov 2013 09:19:51 -0800 (PST)
Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id CC1771ACC8B; Wed, 20 Nov 2013 09:19:51 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.93,738,1378882800"; d="asc'?scan'208"; a="77155212"
Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx11-out.netapp.com with ESMTP; 20 Nov 2013 09:19:36 -0800
Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.244]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 09:19:35 -0800
From: "Eggert, Lars" <lars@netapp.com>
To: "jsaldana@unizar.es" <jsaldana@unizar.es>
Thread-Topic: [tcmtf] Improvements in the TCM-TF charter draft v8
Thread-Index: Ac7l29nMkufifoJCSfepXySzd9rO2QAYJwOAAALQxQAAAemnAAAB9UYAAAAh+gA=
Date: Wed, 20 Nov 2013 17:19:35 +0000
Message-ID: <DF8B1551-94F7-47D4-B887-414D0904FF29@netapp.com>
References: <008b01cee5e1$93b2e460$bb18ad20$@unizar.es> <34D36AB0-C95B-4569-9FBC-6CD58483C78D@netapp.com> <002801cee604$abcb7b20$03627160$@unizar.es> <DD294190-1AFE-4AAE-BF77-9C3F65694A3D@netapp.com> <005301cee614$27a7b600$76f72200$@unizar.es>
In-Reply-To: <005301cee614$27a7b600$76f72200$@unizar.es>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.106.53.51]
Content-Type: multipart/signed; boundary="Apple-Mail=_B5F0D22A-8498-4A77-8FD2-4BE1CD7FFEC1"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Cc: "tcmtf@ietf.org" <tcmtf@ietf.org>, Martin Stiemerling <mls.ietf@googlemail.com>, "tsv-area@ietf.org" <tsv-area@ietf.org>
Subject: Re: [tcmtf] Improvements in the TCM-TF charter draft v8
X-BeenThere: tcmtf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Tunneling Compressed Multiplexed Traffic Flows \(TCMTF\) discussion list" <tcmtf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcmtf/>
List-Post: <mailto:tcmtf@ietf.org>
List-Help: <mailto:tcmtf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcmtf>, <mailto:tcmtf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Nov 2013 17:19:54 -0000

Hi,

On 2013-11-20, at 12:15, Jose Saldana <jsaldana@unizar.es>; wrote:
> - 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).

where does this scenario have multiple L3 hops involved? The bottleneck link is the satellite hop.

> - an air-to-ground connection providing Internet connectivity to the
> passengers of an aircraft, multiplexing a number of simultaneous VoIP flows.

Ditto, the bottleneck here is air-to-ground.

Lars

> Regarding these other two scenarios, perhaps TCM-TF would only be
> interesting when there is a community network in which packets have to
> traverse a (frequently high) number of hops:
> 
> - 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
> 
> For example, in this scenario a community network with a high number of hops
> is considered: http://www.guifi.net/en/guifi_zones. There is also a paper
> about the topology of community networks: "On the topology characterization
> of Guifi.net" http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6379103
> 
> Thanks for your feedback!
> 
> Jose
> 
> -----Mensaje original-----
> De: tcmtf [mailto:tcmtf-bounces@ietf.org] En nombre de Eggert, Lars
> Enviado el: miércoles, 20 de noviembre de 2013 17:20
> Para: jsaldana@unizar.es
> CC: tcmtf@ietf.org; Martin Stiemerling; tsv-area@ietf.org
> Asunto: Re: [tcmtf] Improvements in the TCM-TF charter draft v8
> 
> Hi,
> 
> On 2013-11-20, at 10:24, Jose Saldana <jsaldana@unizar.es>; wrote:
>> 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.
> 
> several of the scenarios you describe for TCM-TF seem to be fully addressed
> by ROHC, i.e., do not seem to have multiple L3 hops that require creation of
> a tunnel.
> 
> It would be good to explicitly limit yourself to describing scenarios that
> do have that requirement.
> 
> Lars
>