Re: [Spud] New Version Notification for draft-herbert-transports-over-udp-00.txt

Michael Welzl <michawe@ifi.uio.no> Sun, 22 May 2016 19:43 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB73B12D587 for <spud@ietfa.amsl.com>; Sun, 22 May 2016 12:43:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.625
X-Spam-Level:
X-Spam-Status: No, score=-5.625 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
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 2mWFtZKk7sB2 for <spud@ietfa.amsl.com>; Sun, 22 May 2016 12:43:56 -0700 (PDT)
Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B112012D119 for <spud@ietf.org>; Sun, 22 May 2016 12:43:55 -0700 (PDT)
Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1b4ZHw-0003BR-4G; Sun, 22 May 2016 21:43:48 +0200
Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.103]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1b4ZHv-0001Iy-EI; Sun, 22 May 2016 21:43:48 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_C4BF7E57-DF79-482D-B087-DD266DFE6A20"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <CAGD1bZZFkWNQ6dnETVoA0oat2h03JscCD6OcZPasFdKTYnkMQQ@mail.gmail.com>
Date: Sun, 22 May 2016 21:43:44 +0200
Message-Id: <D326F273-8736-4079-AF1A-8495320917F8@ifi.uio.no>
References: <CALx6S377qRfq7ufRVUx6Yn7ec4=EmK_=FL14PWT_qf4g840mbQ@mail.gmail.com> <20160519185943.GM12994@cisco.com> <CALx6S37qPpKpCT6ZpVQwRWf1XFKESYasOBcz26To9zw0GRyz5Q@mail.gmail.com> <573E31E1.807@isi.edu> <20160519221102.GS12994@cisco.com> <573E3C5E.2090300@isi.edu> <20160520001323.GC2511@cisco.com> <573E6303.8030701@isi.edu> <20160520012431.GF2511@cisco.com> <573F47C0.3010501@isi.edu> <20160520182115.GO2511@cisco.com> <CALx6S378X7bk5q-u7Kxu+s3w1ZZ5kZcyhCVEUyPG_=hVzNH2tA@mail.gmail.com> <655C07320163294895BBADA28372AF5D48860CBE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <DM2PR0301MB06553A6249DB5BAD06D2A96BA84B0@DM2PR0301MB0655.namprd03.prod.outlook.com> <CALx6S35m9xCvzLqXyLgARdoep_WfZBoLsGFNUVUx8GfxXfiYNg@mail.gmail.com> <CAGD1bZZFkWNQ6dnETVoA0oat2h03JscCD6OcZPasFdKTYnkMQQ@mail.gmail.com>
To: Jana Iyengar <jri@google.com>
X-Mailer: Apple Mail (2.3124)
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 17 msgs/h 4 sum rcpts/h 19 sum msgs/h 5 total rcpts 42002 max rcpts/h 54 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 6BF79A8C9169B1AE366942FB74FF202B78938AD7
X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 1058 max/h 14 blacklist 0 greylist 0 ratelimit 0
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/uhuMYInIdLWcHg7Kv-aJo9msrHM>
Cc: Toerless Eckert <eckert@cisco.com>, Joe Touch <touch@isi.edu>, Tom Herbert <tom@herbertland.com>, "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>, spud@ietf.org, Christian Huitema <huitema@microsoft.com>
Subject: Re: [Spud] New Version Notification for draft-herbert-transports-over-udp-00.txt
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 May 2016 19:43:57 -0000

Hi,

I still didn’t get to read the draft - apologies!  I probably like it  :-)   but I hope it allows putting multiple TCP connections under one single UDP 5-tuple.
Anyway, not speaking pro- or con- this draft, just a comment in line:


> On 22. mai 2016, at 05.03, Jana Iyengar <jri@google.com> wrote:
> 
> Possibly unsurprisingly, I like this draft. I'd like to argue some of the choices made in the draft but I'll do that separately. For now, I just wanted to articulate a few thoughts as I caught up on this thread:
> 
> - The ship has sailed on new native-IP transports. I worked on SCTP for 6 years and tried and watched it get nowhere in terms of deployment over native-IP. It wasn't because it was in the kernel, it was primarily because of NATs and various middleboxes. Yes this is definitely my opinion, but arguing this point is silly. No new native IP transport has seen significant deployment over the internet over the past 20 years, and it's not for lack of trying.
> 
“The ship has sailed” and “it’s not for lack of trying” are both wrong IMO. How many applications have tried to use SCTP/IP and fallen back to TCP in case it doesn’t work? How many applications do you expect to change in order to get such a change to happen? And why should anyone expect someone designing or maintaining a router or middlebox to support native SCTP when they never even see the packets and never even hear anyone say “my application works better elsewhere because of SCTP” ?

This is what TAPS is trying to address. It’s a very deep architectural problem of the Internet - an inability to automate fall-backs, which unnecessarily burdens application developers. Rant, rant, rant, make me stop   :-)

Now all this being said, I also don’t fully get why some folks have such a big problem with running stuff over UDP. I’m not against doing that, if only as a temporary solution that would serve to convince people that the transport (option, ..) is useful.
In a TAPS world, it’s just another option to try…

Cheers,
Michael