IETF Logo Mail Archive

Re: [Spud] updated draft PLUS charter, rev. 1 June

Brian Trammell <ietf@trammell.ch> Tue, 14 June 2016 14:52 UTC

Return-Path: <ietf@trammell.ch>
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 6E99512D78A for <spud@ietfa.amsl.com>; Tue, 14 Jun 2016 07:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.328
X-Spam-Level:
X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 3RbV0QMjfAHw for <spud@ietfa.amsl.com>; Tue, 14 Jun 2016 07:52:20 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 61F4F12D7AD for <spud@ietf.org>; Tue, 14 Jun 2016 07:43:57 -0700 (PDT)
Received: from [IPv6:2001:67c:10ec:2a49:8000::10d6] (unknown [IPv6:2001:67c:10ec:2a49:8000::10d6]) by trammell.ch (Postfix) with ESMTPSA id 52BCB1A0106; Tue, 14 Jun 2016 16:43:55 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_5B1BC5B8-1887-47F1-96BC-0CA7448F05A4"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.6b2
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <EA4C43BE752A194597B002779DF69BAE24100840@ESESSMB303.ericsson.se>
Date: Tue, 14 Jun 2016 16:43:54 +0200
Message-Id: <273B68FC-7E86-4F5B-85BF-EA5F01AED2B0@trammell.ch>
References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <CAD62q9UiLi1ffGPm=xEXOSH=sqZPv7hYiNBTGvAX52a9dhV8yg@mail.gmail.com> <CAD62q9U7XL8hDqY1VdzuvUvoz0Ec5DDLAS6=kaLxRExu7FY0Kg@mail.gmail.com> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <A4C63A75-9D7E-430E-B986-9981FB929D46@gmail.com> <CA+9kkMBhJ2oCJ1avnGUY4NYTX0VWA_g=YoJSiLcy6u9hJnH-eA@mail.gmail.com> <57573DCF.1030402@isi.edu> <F6BE4EE1-D320-421E-9D86-2F30B2A88792@tik.ee.ethz.ch> <CALx6S35Z7iEp2F7+1PHzAe0qu9st_CNXB9GCzF278HehFiv0Qg@mail.gmail.com> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <CALx6S35KXOioEK60p-m5tGE_H9MWbB=YhJ_sOcW0KP2vR80vvw@mail.gmail.com> <57574C38.6070402@isi.edu> <F44FFD3B-CE7E-45E8-9F04-233C56CA95A0@trammell.ch> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> <EA4C43BE752A194597B002779DF69BAE24100840@ESESSMB303.ericsson.se>
To: Szilveszter Nadas <Szilveszter.Nadas@ericsson.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/y1EahiMolxhfabcI7Ic1sZOMhLY>
Cc: spud <spud@ietf.org>, Joe Touch <touch@isi.edu>
Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June
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: Tue, 14 Jun 2016 14:52:21 -0000

> On 13 Jun 2016, at 17:21, Szilveszter Nadas <Szilveszter.Nadas@ericsson.com> wrote:
> 
> Hi,
> 
> 
>> It would be useful if whatever comes out of an eventual PLUS working group
>> could be implemented either over UDP or IPv6 EH, since the lack of access to
>> EH problem is simply a matter of changing APIs. But I'm not convinced that's a
>> hard requirement.
> 
> Is a separate protocol number for SPUD also an option?


It doesn't seem to me that using an alternate protocol number for PLUS (or QUIC) actually meets the requirements of either effort. One is the ability to run on unmodified kernels, which is a somewhat bigger deal for QUIC than for PLUS. Another is middlebox transparency, where experience with SCTP has not been great. True, we don't have a lot of data here; on our list of path transparency measurements to run at ETH is "UDP/TCP with mangled protocol number"; I suspect that NAPT breaks in the overwhelming majority of cases here.

In a world in which every kernel is relatively quickly updatable, NAPT is irrelevant, and other middlebox brokenness negligent, alternate protocol numbers are an option. We are somewhat closer to that world, I think, than we were a decade ago. But I don't think we live in it yet.

> Then the happy eyeball mechanism used could also consider that.

I'm not sure how the protocol number is relevant to happy eyeballs... can you expand on this a bit?

Cheers,

Brian

> Cheers,
> Sz.

v2.23.0 | Report a Bug | By Email