[Spud] A few comments on Brian's proposal

"Fossati, Thomas (Nokia - GB)" <thomas.fossati@nokia.com> Fri, 22 July 2016 10:31 UTC

Return-Path: <thomas.fossati@nokia.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 101DD12DFDE for <spud@ietfa.amsl.com>; Fri, 22 Jul 2016 03:31:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id bWHxbbWxyu-r for <spud@ietfa.amsl.com>; Fri, 22 Jul 2016 03:31:13 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com []) (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 2F99212DFD7 for <spud@ietf.org>; Fri, 22 Jul 2016 03:31:13 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown []) by Websense Email Security Gateway with ESMTPS id A7F0995E23070 for <spud@ietf.org>; Fri, 22 Jul 2016 10:31:08 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com []) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6MAVAML008118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <spud@ietf.org>; Fri, 22 Jul 2016 10:31:11 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com []) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u6MAUnEr002293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <spud@ietf.org>; Fri, 22 Jul 2016 12:31:10 +0200
Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([]) with mapi id 14.03.0195.001; Fri, 22 Jul 2016 12:31:00 +0200
From: "Fossati, Thomas (Nokia - GB)" <thomas.fossati@nokia.com>
To: "spud@ietf.org" <spud@ietf.org>
Thread-Topic: A few comments on Brian's proposal
Thread-Index: AQHR5AQjYx+nd6Tx8ke3LkmcV7dl4w==
Date: Fri, 22 Jul 2016 10:31:00 +0000
Message-ID: <D3B7AA68.6E741%thomas.fossati@alcatel-lucent.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <97B38684F7701A439505654066DA0A12@exchange.lucent.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/5K40Wlyb2W9EdOIWDaXpDh0nyz0>
Subject: [Spud] A few comments on Brian's proposal
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 10:31:15 -0000


One thing that I like about the PLUS co-operative game, as currently
proposed, is that you can set a precise goal for it, and subverting the
game is going to be very hard because users are in control of what they
leak to the path.
Another pleasant thing, is that opt-in is not a boolean flag, but rather a
multi-dimensional variable that users can slice the way they want at any
time depending on the game they want to play (even reducing it to zero
dimensions if they want to stay out of any game).
This looks like very good design to me.

Now, the goal we are looking at is direct/indirect ways to improve users'
QoE.  (Mobile NwOs and users are aligned on this -- for different reasons
of course, yet aligned, and this is the only thing that matters.)
PLUS would give us a solid platform to build the needed signalling in a
pretty straightforward way.
All the use cases we are working on (i.e., adaptive video flows through
the mobile network, radio traffic scheduling) depend on in-band
signalling, so if we had to do that ourselves we'd probably reinvent PLUS.

Other people have use cases that are more on the side of "give me back the
ability to do proper network management" which certainly need to be
tackled.  But I would not narrow PLUS' scope down to those use cases only.
There is a great line that the minutes attribute to Mark that starts with:
"By standardizing this, we might make new things possible.", which I
wholeheartedly agree with: the innovation potential in PLUS is exactly
what we want to explore and are excited about.  And then continues with:
"That worries me, because I don't understand how this impacts end users."
Well, that doesn't worry me at all, and for a couple of good reasons:
1. PLUS' architecture gives me enough guarantees that the QoE game that I
want to enable is not going to be easily subverted;
2. The vocabulary is not yet defined, and this is where the discussion
about users' privacy would certainly happen involving the relevant

If it's not yet clear: I support the creation of this working group :-)
and also plan to contribute with drafts, reviews, and running code.

Cheers, t