Re: [Spud] questions on the BoF outcome

G Fairhurst <gorry@erg.abdn.ac.uk> Fri, 22 July 2016 16:44 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 883CF12DC96 for <spud@ietfa.amsl.com>; Fri, 22 Jul 2016 09:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.186
X-Spam-Level:
X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, WEIRD_PORT=0.001] 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 FoFtwoLr5pT8 for <spud@ietfa.amsl.com>; Fri, 22 Jul 2016 09:44:19 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id C95C312D790 for <spud@ietf.org>; Fri, 22 Jul 2016 09:44:18 -0700 (PDT)
Received: from dhcp-974a.meeting.ietf.org (unknown [IPv6:2001:67c:370:136:50de:9034:beb0:2f00]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id B7BEB1B0007D; Fri, 22 Jul 2016 17:44:12 +0100 (BST)
Message-ID: <57924D61.5090808@erg.abdn.ac.uk>
Date: Fri, 22 Jul 2016 18:44:17 +0200
From: G Fairhurst <gorry@erg.abdn.ac.uk>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Toerless Eckert <eckert@cisco.com>
References: <D3B7A676.6E71A%thomas.fossati@alcatel-lucent.com> <EA4C43BE752A194597B002779DF69BAE241328D0@ESESSMB303.ericsson.se> <CAKcm_gMn3ubbSs7t2Vk6FkSUqFDn4x_Lm6c5gfM_-Nwx8Vy1-Q@mail.gmail.com> <20160722145711.GP7377@cisco.com>
In-Reply-To: <20160722145711.GP7377@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/AAb0yChhoXHwzca0VXK2uk2xThU>
Cc: "Fossati, Thomas \(Nokia - GB\)" <thomas.fossati@nokia.com>, Szilveszter Nadas <Szilveszter.Nadas@ericsson.com>, Ian Swett <ianswett@google.com>, "spud@ietf.org" <spud@ietf.org>
Subject: Re: [Spud] questions on the BoF outcome
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: Fri, 22 Jul 2016 16:44:22 -0000

I'm also hoping this proceeds. We need a framining like this to allow us 
to continue transport inovation.

Being able to see, but also protect (MAC) certain protocol fields in the 
transport header seems a positive step towards ensuring end-to-end 
semantics as we look at new protocols. From this perspective, it is sooo 
much better than using a TCP header field, RTP option, or IPv6 header.

Gorry

On 22/07/2016, 16:57, Toerless Eckert wrote:
> Whats actually the official process for asking for support - only
> Hum i the WG, or is there going to be a call here or whatever other
> mailing list ?
>
> If anyone is counting, here's one in favor of Plus WG.
>
> Use-case: Controlled network edge to Internet firewalls wanting to have similar
> flow recognition to TCP for UDP flows with replay-safe intent to receive
> indication.
>
> Cheers
>      Toerless
>
> On Fri, Jul 22, 2016 at 10:48:47AM -0400, Ian Swett wrote:
>> I hummed no largely because I felt I didn't clearly understand the work of
>> the group, and hence couldn't evaluate whether it was possible and
>> desirable.
>>
>> I personally would have preferred a clearly scoped set of initial use
>> cases, with other use cases of potential future interest requiring a
>> re-charter.
>>
>> I believe there are a lot of people interested in something along these
>> lines, so my no hum was not an expression they should stop trying to move
>> forward with a WG.  I also want to continue having the conversation about
>> what the path needs at the IETF, because it comes up fairly often, but I
>> feel there's currently no coherent forum for the conversation.
>>
>> It would be great to see some amount of running code as well, with some
>> clearly improved metrics for that particular use case.  I would hope small
>> scale experiments would inform the WG on what topics may warrant a
>> re-charter.
>>
>> On Fri, Jul 22, 2016 at 6:29 AM, Szilveszter Nadas<
>> Szilveszter.Nadas@ericsson.com>  wrote:
>>
>>> Hi,
>>>
>>> Some other argument was e.g. overhead. There was a significant amount of
>>> "NO" hums for the first question, the rest of the questions was not even
>>> asked.
>>>
>>> It is also not clear to me, is there still hope, or is it hat eating time?
>>> :)
>>>
>>> Cheers,
>>> Sz.
>>>
>>>> -----Original Message-----
>>>> From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Fossati, Thomas
>>>> (Nokia - GB)
>>>> Sent: Friday, July 22, 2016 12:26
>>>> To: spud@ietf.org
>>>> Subject: [Spud] questions on the BoF outcome
>>>>
>>>> Hi,
>>>>
>>>> Unfortunately I could not attend the PLUS BoF.  So, I've just gone
>>> through the
>>>> minutes [1] (thanks a lot, scribes) and got the feeling that this work
>>> is pushed
>>>> back due to the perception that it'd weaken users' privacy?
>>>>
>>>> I hear these arguments:
>>>> - "potential to compel clients to send metadata or packets will dropped"
>>>>
>>>> But that could have happened already if the network wanted to (just drop
>>> any
>>>> TCP payload that starts with 0x16 and allow only clear-text traffic!).
>>>>   Access networks that you pay for do not have that incentive though, so
>>> I'm
>>>> very skeptical this could now happen *because of* PLUS.
>>>>
>>>> - "possibility for abuse"
>>>>
>>>> Well, that depends on the metadata that *users* decide to leak (which is
>>> a
>>>> separate discussion on the vocabulary), but in general Brian's framework
>>> looks
>>>> pretty well designed to bias control towards the endpoints which can act
>>> as
>>>> circuit-breakers at any point in time.
>>>>
>>>> - "giving more power to the network";
>>>>
>>>> This is actually true, but in a good way: the network will have power to
>>> send
>>>> useful information to the endpoints -- if it's asked to -- while being
>>> empowered
>>>> by the signalling coming from the endpoints (e.g., for DDoS prevention).
>>>>
>>>> So, sorry but this looks a lot like FUD to me.
>>>>
>>>> Is the working group not formed on these grounds?  Or have more
>>> substantial
>>>> weaknesses been highlighted during the discussion that have not been
>>>> captured in the minutes?
>>>>
>>>> Cheers, thanks,
>>>> t
>>>>
>>>> [1] http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-plus
>>>>
>>>> _______________________________________________
>>>> Spud mailing list
>>>> Spud@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/spud
>>> _______________________________________________
>>> Spud mailing list
>>> Spud@ietf.org
>>> https://www.ietf.org/mailman/listinfo/spud
>>>
>> _______________________________________________
>> Spud mailing list
>> Spud@ietf.org
>> https://www.ietf.org/mailman/listinfo/spud
>