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

Yoav Nir <ynir.ietf@gmail.com> Sun, 03 July 2016 15:39 UTC

Return-Path: <ynir.ietf@gmail.com>
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 F1F6312D119 for <spud@ietfa.amsl.com>; Sun, 3 Jul 2016 08:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 IVFEPx7G-BHG for <spud@ietfa.amsl.com>; Sun, 3 Jul 2016 08:39:37 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12A1312D0A4 for <spud@ietf.org>; Sun, 3 Jul 2016 08:39:37 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id 187so17533453wmz.1 for <spud@ietf.org>; Sun, 03 Jul 2016 08:39:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MtzcwqBqiDnaTlK+LGGoy9XaKOLboJzH884JioroQdo=; b=ZYvSIRqS+RmfGYatrMC7UOC+wXw4d1dBBciiqxRif2mu0Rg1Y1M33yegoohKKkNqSV u6rRVRe5pbn+IFJ2OplABK7DAhugeIGTuaBw9WwNjmNNyswzBgEgFelhtl/Qa74LkNvF XY75qgMjmlnXL49F4lBEB5yHCNCWZ5tNadF2Grmh1U0WZ+dKvAasXjBtPDoX5UoLW5+D 81sEPjQV8JMMAt3LwXvVacJivw510UExGy+OHuGe7LroYYa1ODqsrUuSHirRQYzE2QNN a4kzmZMmNOH4rliieCbl0J6lajhVKHqm17hi1cRv3Dv5xDLhzQJ9rhCxWvOhDovE7fgD 3JlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MtzcwqBqiDnaTlK+LGGoy9XaKOLboJzH884JioroQdo=; b=h8Hxn8dt1Lhq5UTsCdhBd1NfRe0/thMRAZyaZ+5z4+Pk8JI8SMWhwg+APbaxZlqY+p ixJzpm5igQuxJYTzziZXVHGa+BmTu6uzNAWAYoapHvOSpkRHQF1f62BT2snEw4ty+GFM Wyd+Ii+4vK3aYwbRh+I7GQkNGSTSyNVZgeWVK37CizZZB6GL6fgGg08r6eTlq/eQi/Aw AfW2A1TFx6z6pqS4MMDX7hl9vhAtcZuw3CPIcDXd5q9w8v3f3pSmbeP/A2BWI9ulug7/ 0tT7Pr2QZGOFgaDmKvq0RZM6ep/5KIE7nPfHpbcCt/YA+YBdQzm3i8WpKWcc7/VzJamO 45cQ==
X-Gm-Message-State: ALyK8tLY19LCyd8QTqj1fpeYa0/2MJNoKKyv17GyN6bo2xDNkKWDWSrHKJiTF9ErJoeSHA==
X-Received: by 10.28.69.134 with SMTP id l6mr6990461wmi.80.1467560375466; Sun, 03 Jul 2016 08:39:35 -0700 (PDT)
Received: from [172.24.249.249] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id ej9sm5438004wjd.7.2016.07.03.08.39.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 03 Jul 2016 08:39:34 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <CALx6S37Sz6HkmGFPKcJmbTcnro9b4jaD7a+ix6Q1C9Td+ejLcg@mail.gmail.com>
Date: Sun, 3 Jul 2016 18:39:30 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <163067B5-A5AC-4360-985F-D54A235A1093@gmail.com>
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> <CAD6AjGTiSu7Lcfq_fdfva1Z5xM0ReQL+tk4UabE7=g7yjGG4CQ@mail.gmail.com> <DM2PR0301MB0655C4B5A3A7E4102D16DBC6A8540@DM2PR0301MB0655.namprd03.prod.outlook.com> <BB04CCB1-0CF6-437F-B4D1-4CED87DF9864@trammell.ch> <CAD6AjGSCdxk9pY8mX5gR1qoC_ck+ggKvCK7CyLkpp_4T1Th1QA@mail.gmail.com> <CALx6S37Sz6HkmGFPKcJmbTcnro9b4jaD7a+ix6Q1C9Td+ejLcg@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/XYmxjGjcjycftDa_25FDAp-dRb0>
Cc: Szilveszter Nadas <Szilveszter.Nadas@ericsson.com>, Joe Touch <touch@isi.edu>, spud <spud@ietf.org>, Brian Trammell <ietf@trammell.ch>, Ca By <cb.list6@gmail.com>, Christian Huitema <huitema@microsoft.com>
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: Sun, 03 Jul 2016 15:39:39 -0000

> On 26 Jun 2016, at 12:32 AM, Tom Herbert <tom@herbertland.com> wrote:
> 
>>> 
>>> 
>> 
>> Is there anyone from a middle box vendor here? Do you want to hear what PLUS
>> is telling you? Or will middleboxes keep doing what they want?
>> 
> +1, these are very important questions to be answered for PLUS effort.

Well, I hesitate to speak for all middlebox vendors, but I work for a firewall vendor, and I’ve been told that firewalls are the second most problematic middlebox ([1]).

So IMO middleboxes will do whatever their developers feel is necessary to accomplish the box’s job. If PLUS tells the middlebox things that allow it to do its job better or cheaper, they will listen. 

For example, if PLUS marks some flows as latency-sensitive and others as loss-sensitive, middleboxes that perform q QoS function are likely to listen.

Similarly, information that would help in filtering (although I can’t off-hand think of an example) would be used by a firewall/IDS. If a firewall/IDS currently performs TLS proxy functionality to make some categorization, and the same categorization can be made on the basis of PLUS data, that would be a win for both usability and performance. 

> 
>> I am concerned plus is saying things nobody is listening to.
>> 
> Unless somebody's listening, there's no reason to believe applications
> are going to bother to say anything.

I agree that this would be important input for a potential WG. It would be appropriate to find a use-case for why somebody would listen for anything someone proposes that the applications say.

Yoav

[1] First place being buggy middleboxes from defunct vendors that will never ever get updated.