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
- [tcmtf] TCMTF BOF description Jose Saldana
- Re: [tcmtf] TCMTF BOF description Julián Fernández-Navajas
- Re: [tcmtf] TCMTF BOF description Martin Stiemerling
- Re: [tcmtf] TCMTF BOF description Jose Saldana