Re: Appointment of a Transport Area Director

Carsten Bormann <cabo@tzi.org> Tue, 05 March 2013 21:13 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2F411E8118 for <ietf@ietfa.amsl.com>; Tue, 5 Mar 2013 13:13:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level:
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 b92nUpOcEg3Z for <ietf@ietfa.amsl.com>; Tue, 5 Mar 2013 13:13:03 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 742D411E8109 for <ietf@ietf.org>; Tue, 5 Mar 2013 13:13:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r25LCvp9008610; Tue, 5 Mar 2013 22:12:57 +0100 (CET)
Received: from [192.168.217.105] (p548943EA.dip.t-dialin.net [84.137.67.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E04BF385C; Tue, 5 Mar 2013 22:12:56 +0100 (CET)
Subject: Re: Appointment of a Transport Area Director
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: text/plain; charset="iso-8859-1"
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <51363249.1000605@isi.edu>
Date: Tue, 05 Mar 2013 22:12:43 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <47029AA2-8072-490A-988A-826577B582B5@tzi.org>
References: <21B86E13-B8DA-4119-BBB1-B5EE6D2B5C1D@ietf.org><51330179.3040500@gmail.com><919840EE-BEC8-4F82-8D3C-B116698A4262@gmx.net><1D88E6E9-33DE-4C4D-89F4-B0B762155D6F@standardstrack.com><D4D47BCFFE5A004F95D707546AC0D7E91F77BA46@SACEXCMBX01-PRD.hq.netapp.com><3CB8992B-212A-4776-95FE-71CA1E382FFF@standardstrack.com><513376DB.7000200@dcrocker.net><E22ACC99-B465-4769-8B59-BB98A7BA93DF@gmx.net><79E77523-3D92-4CE9-8689-483D416794EF@standardstrack.com><D4D47BCFFE5A004F95D707546AC0D7E91F780D2F@SACEXCMBX01-PRDfg0=r38mkcJ4zqoJeTw@mail.gmail.com><tslr4julxmh.fsf@mit.edu> <031e01ce198d$8e408800$4001a8c0@gateway.2wire.net><5135D35D.2060909@neclab.eu>, <033901ce1996$9c8258e0$4001a8c0@gateway.2wire.net> <290E20B455C66743BE178C5C84F124081A49EEF286@EXMB01CMS.surrey.ac.uk> <003301ce19ab$40e6e9a0$4001a8c0@gateway.2wire.net> <D4D47BCFFE5A004F95D707546AC0D7E91F787238@SACEXCMBX01-PRD.hq.netapp.com> <51363249.1000605@isi.edu>
To: braden@isi.edu
X-Mailer: Apple Mail (2.1499)
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2013 21:13:04 -0000

On Mar 5, 2013, at 18:58, Bob Braden <braden@isi.edu> wrote:

> Which is why we learned 30 years ago that building a transport protocol at the application layer is generally a Bad Idea. Why do the same bad ideas keep being reinvented?

Because we don't have a good selection of transport protocols at the transport layer.

I'm chairing one of the WGs with a UDP-based application protocol.
TCP's congestion control, even if we could use TCP, wouldn't do much for us.

Now here is my point:
I need TSV ADs that are strong on the technical side.
A weak TSV AD might be
-- too cautious, listening to all kinds of Cassandras that haven't bothered to look at the actual protocol, slowing us down unneededly, or
-- too bold, allowing us to deploy a protocol that causes a congestion collapse that can only be alleviated by physically chiseling nodes out of walls.

Clearly, I want neither of these to happen.
(Now, we have received pretty good transport input in 2012, but the IESG will look at this in 2013, and that's where a highly educated decision has to be made.)

Grüße, Carsten