[tcmtf] RV: Thank you for a great BoF!
"Jose Saldana" <jsaldana@unizar.es> Wed, 12 March 2014 08:23 UTC
Return-Path: <jsaldana@unizar.es>
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 172C01A0916 for <tcmtf@ietfa.amsl.com>; Wed, 12 Mar 2014 01:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.034
X-Spam-Level:
X-Spam-Status: No, score=-4.034 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ONE_TIME=0.714, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 Q-0UBeagS_D9 for <tcmtf@ietfa.amsl.com>; Wed, 12 Mar 2014 01:23:27 -0700 (PDT)
Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 503751A08FA for <tcmtf@ietf.org>; Wed, 12 Mar 2014 01:23:26 -0700 (PDT)
Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s2C8NEYN010897; Wed, 12 Mar 2014 09:23:14 +0100
From: Jose Saldana <jsaldana@unizar.es>
To: Martin Stiemerling <mls.ietf@gmail.com>
References: <6FE75E93-FF8E-4435-B2D6-6A44668D5AA7@tik.ee.ethz.ch> <E2DF4029-47D4-415E-9F9F-D9C5153A5F62@trammell.ch>
In-Reply-To: <E2DF4029-47D4-415E-9F9F-D9C5153A5F62@trammell.ch>
Date: Wed, 12 Mar 2014 09:23:18 +0100
Message-ID: <008301cf3dcc$52b8f6f0$f82ae4d0$@unizar.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHzuOG1bU6Xk0Mlov/nfhNUFohXjwJwnHIamoCe0sA=
Content-Language: es
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Archived-At: http://mailarchive.ietf.org/arch/msg/tcmtf/fmUHoPrjDgyKatHUlbvxfN7qcPU
Cc: tcmtf@ietf.org, 'Spencer Dawkins' <spencerdawkins.ietf@gmail.com>
Subject: [tcmtf] RV: Thank you for a great BoF!
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, 12 Mar 2014 08:23:30 -0000
Hi, Martin, According to the summary of Brian and Mirja, there are three potential improvements for the TCM-TF charter draft. I have added some comments below. Should we prepare a new version of the charter? > -----Mensaje original----- > De: tcmtf [mailto:tcmtf-bounces@ietf.org] En nombre de Brian Trammell > Enviado el: miƩrcoles, 05 de marzo de 2014 14:51 > Para: tcmtf@ietf.org > Asunto: [tcmtf] Thank you for a great BoF! > > Greetings, all, > > Thanks to everyone for yesterday's BoF. We got lots of good input, and a > better handle on what a future TCMTF WG might look like. > > There are a few issues we identified that we'll have to take into > consideration for a new draft of the charter: > > (1) make it clear that backward compatibility with RFC 4170 is a goal. I think there is no problem with maintaining backwards compatibility. I sent some suggestions for improving the charter: http://www.ietf.org/mail-archive/web/tcmtf/current/msg00524.html > > (2) an applicability statement, which explains applications that benefit from > TCMTF and the situations for which it is likely useful, and applications > and situations for which it is not. The current n.4 of the charter is about this (http://www.ietf.org/mail-archive/web/tcmtf/current/msg00493.html) Should we improve it?: 4. New scenarios where bandwidth savings are desirable have been identified, in addition to those considered in RFC4170. In these scenarios, there are moments or places where network capacity gets scarce, so allocating more bandwidth is a possible solution, but it implies a recurring cost. However, the inclusion of a pair of boxes able to optimize the traffic when/where required is a one-time investment. These scenarios can be classified into: * Multidomain, the TCMT-TF tunnel goes all the way from one network edge to another, and can therefore cross several domains. * Single Domain, TCM-TF is only activated inside an ISP, from the edge to border inside the network operator. * Private Solutions. TCM-TF is used to connect private networks geographically apart (e.g. corporation headquarters and subsidiaries), without the ISP being aware or having to manage those flows. * Mixed Scenarios, any combination of the previous ones. > This should address interactions between > TCMTF tunnels and TCP cross traffic sharing a bottleneck link. This should have to be added to the charter, but I don't clearly understand what is this problem about. If we compress UDP flows, then we have more bandwidth for TCP flows sharing the bottleneck. Where is the problem? Perhaps I missed something in the discussion. > > (3) interactions with how this interacts with diverse lower layers, especially > with respect to different delay tolerances, will have to be considered. > Is this covered by n.7? Perhaps some sentences could be added: 7. As a counterpart of the bandwidth saving, TCM-TF may add some delay and jitter. This is not a problem for the services which are not sensitive to delay. However, regarding delay-sensitive services, the Working Group will also develop a document (TCM-TF - recommendations) with useful recommendations in order to decide which packet flows can or can not be multiplexed and how. The document will present a list of available traffic classification methods which can be used for identification of the service or application to which a particular flow belongs, as well as recommendations of the maximum delay and jitter to be added depending of the identified service or application. The eventual impact of multiplexing on protocol dynamics (e.g. the loss of a multiplexed packet, MTU-related issues) will also have to be addressed. > And we'd really more input from vendors already building boxes in this > space, and operators deploying them, as input to scoping and applicability. > We have some messages in the list: http://www.ietf.org/mail-archive/web/tcmtf/current/msg00490.html http://www.ietf.org/mail-archive/web/tcmtf/current/msg00497.html http://www.ietf.org/mail-archive/web/tcmtf/current/msg00491.html http://www.ietf.org/mail-archive/web/tcmtf/current/msg00498.html > Best regards, > > Mirja and Brian (second TCMTF BoF chairs) > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf Thanks a lot, Jose
- [tcmtf] Thank you for a great BoF! Brian Trammell
- [tcmtf] RV: Thank you for a great BoF! Jose Saldana
- Re: [tcmtf] Thank you for a great BoF! Brian Trammell
- Re: [tcmtf] Thank you for a great BoF! Jose Saldana