[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