Re: [tcmtf] TCMTF-Feedback about a possible BoF in London

Wesley Eddy <wes@mti-systems.com> Thu, 09 January 2014 18:04 UTC

Return-Path: <wes@mti-systems.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 AD0111AE057 for <tcmtf@ietfa.amsl.com>; Thu, 9 Jan 2014 10:04:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 YY2rJNHTQ5l8 for <tcmtf@ietfa.amsl.com>; Thu, 9 Jan 2014 10:04:01 -0800 (PST)
Received: from atl4mhob08.myregisteredsite.com (atl4mhob08.myregisteredsite.com [209.17.115.46]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5D41AE04C for <tcmtf@ietf.org>; Thu, 9 Jan 2014 10:04:01 -0800 (PST)
Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob08.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s09I3o19005537 for <tcmtf@ietf.org>; Thu, 9 Jan 2014 13:03:50 -0500
Received: (qmail 8367 invoked by uid 0); 9 Jan 2014 18:03:50 -0000
X-TCPREMOTEIP: 107.46.60.198
X-Authenticated-UID: wes@mti-systems.com
Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.46.60.198) by 0 with ESMTPA; 9 Jan 2014 18:03:49 -0000
Message-ID: <52CEE47E.5020804@mti-systems.com>
Date: Thu, 09 Jan 2014 13:03:42 -0500
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Tina TSOU <Tina.Tsou.Zouting@huawei.com>, Jose Saldana <jsaldana@unizar.es>
References: <00c401cefd65$6e8ef570$4bace050$@unizar.es> <8D3D17ACE214DC429325B2B98F3AE712026EF2FF8F@MX15A.corp.emc.com>, <004701cf0ccf$4d5826a0$e80873e0$@unizar.es> <B180C070-CA16-47BE-9A43-1F10546426DA@huawei.com>
In-Reply-To: <B180C070-CA16-47BE-9A43-1F10546426DA@huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "tcmtf@ietf.org" <tcmtf@ietf.org>, Luigi Iannone <ggx@gigix.net>, "Black, David" <david.black@emc.com>, "tsv-area@ietf.org" <tsv-area@ietf.org>, Martin Stiemerling <mls.ietf@googlemail.com>
Subject: Re: [tcmtf] TCMTF-Feedback about a possible BoF in London
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: Thu, 09 Jan 2014 18:04:02 -0000

On 1/8/2014 7:49 PM, Tina TSOU wrote:
> Dear all,
> I'm in favor of having a BoF in London, as the following problem
> statement seems valid and needs protocol work in IETF.
> ...

I'm in agreement as well.  Parts of the problem statement and the
scope of the work might still be tweakable, but I think that
overall there is important work for the IETF to do in this area.

Due to the things Tina described very well, there will be (and are)
products available that attempt to optimize traffic in poorly
documented and often poorly conceived ways.  These can do more harm
and have other mysterious effects on traffic than whatever this
working group would create, since it would provide open specifications
that could be developed and tested against the concerns of relevant
layers and other IETF protocols, and problems and concerns could be
addressed.

If there are people willing to write the specs *and* people are
also able to express interest in writing/deploying/selling code and
products that use those specs, then we should certainly be doing
this work in the IETF.

This will allow:
- multiple vendor boxes to interoperate on different sides of a
  challenged network/link (currently this is beyond the state of
  the art!)
- simplified/standardized management of such boxes
- well-understood behavior profiles of such middleboxes and their
  protocols algorithms

If the IETF does not do this work, then I don't believe any of those
three benefits/results are likely at all, and the (poor) status quo
will continue.

-- 
Wes Eddy
MTI Systems