Re: [tcmtf] TCMTF BOF description

Julián Fernández-Navajas <navajas@unizar.es> Thu, 06 June 2013 08:07 UTC

Return-Path: <navajas@unizar.es>
X-Original-To: tcmtf@ietfa.amsl.com
Delivered-To: tcmtf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A520B21F934B for <tcmtf@ietfa.amsl.com>; Thu, 6 Jun 2013 01:07:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.298
X-Spam-Level:
X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFJ3QH4avUeJ for <tcmtf@ietfa.amsl.com>; Thu, 6 Jun 2013 01:07:50 -0700 (PDT)
Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0C621F9310 for <tcmtf@ietf.org>; Thu, 6 Jun 2013 01:07:49 -0700 (PDT)
Received: from [155.210.156.37] (tele3.cps.unizar.es [155.210.156.37]) (authenticated bits=0) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r5687fO2024048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <tcmtf@ietf.org>; Thu, 6 Jun 2013 10:07:46 +0200
Message-ID: <51B0434D.9030205@unizar.es>
Date: Thu, 06 Jun 2013 10:07:41 +0200
From: =?ISO-8859-15?Q?Juli=E1n_Fern=E1ndez-Navajas?= <navajas@unizar.es>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: tcmtf@ietf.org
References: <004e01ce61de$493b4c60$dbb1e520$@unizar.es>
In-Reply-To: <004e01ce61de$493b4c60$dbb1e520$@unizar.es>
Content-Type: multipart/alternative; boundary="------------000401050300070902000606"
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Subject: Re: [tcmtf] TCMTF BOF description
X-BeenThere: tcmtf@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 06 Jun 2013 08:08:01 -0000

Hi all,
I'd like to make a remark.
I feel that the charter is only oriented to network operator. Perhaps it 
is good strengthen the idea that TCMTF is also beneficial for the 
development of end-to-end aplications.
Julián


El 05/06/2013 13:17, Jose Saldana escribió:
>
> Hi,
>
> I have just built this BOF description for 
> http://trac.tools.ietf.org/bof/trac/wiki. It summarizes the draft charter:
>
> Some emerging interactive services (VoIP, videoconferencing, 
> telemedicine, video vigilance, online gaming, etc.) use small packets 
> in order to send frequent updates to the other extreme of the 
> communication. Therefore, its overhead is significant. In addition, 
> some other services also send small packets, although they are not 
> delay-sensitive (e.g., instant messaging, m2m packets sending 
> collected data in sensor networks using wireless or satellite scenarios).
>
> When a number of small-packet flows share the same path, bandwidth can 
> be saved by multiplexing packets belonging to different flows, adding 
> a small multiplexing delay as a counterpart. This delay has to be 
> maintained under some threshold in order to grant the delay 
> requirements. Some examples of the scenarios where grouping packets is 
> possible are: aggregation networks of a network operator; a tunnel 
> between two premises of the same company; a satellite connection used 
> for collecting the data of a high number of sensors.
>
> RFC4170 <http://tools.ietf.org/html/rfc4170> (TCRTP) defined a method 
> for grouping VoIP packets considering three different layers: header 
> compression by means of ECRTP; multiplexing by means of PPPMux; 
> tunneling by means of L2TPv3. However, in the last years, emerging 
> real-time services which do not use UDP/RTP have become popular: some 
> of them use UDP or even TCP. In addition, new header compression 
> methods have been defined (ROHC). So there is a need of widening the 
> scope of RFC4170 in order to consider not only UDP/RTP but also other 
> protocols. The same structure of three layers will be considered: 
> header compression, multiplexing and tunneling.
>
> The BOF aims for the creation of a Working Group in order to specify 
> the protocol stack, signaling mechanisms and maximum added delay 
> recommendations for tunneling, compressing and multiplexing traffic 
> flows (TCMTF).
>
> Do you like it?
>
> Another thing: in the section Relevant I-Ds of the web page, the 
> "recommendations" draft could also be included:
>
> http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/
>
> Best regards,
>
> Jose
>
>
>
> _______________________________________________
> tcmtf mailing list
> tcmtf@ietf.org
> https://www.ietf.org/mailman/listinfo/tcmtf