[Spud] New PLUS mailing list, side meeting and future steps

Mirja K├╝hlewind <mirja.kuehlewind@tik.ee.ethz.ch> Mon, 05 December 2016 14:55 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.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 74873129512; Mon, 5 Dec 2016 06:55:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.116
X-Spam-Level:
X-Spam-Status: No, score=-7.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896] 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 hcIKtYf8xpKI; Mon, 5 Dec 2016 06:55:18 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F4C129A21; Mon, 5 Dec 2016 06:55:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 502C8D9305; Mon, 5 Dec 2016 15:45:28 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9-xGMlqJmonr; Mon, 5 Dec 2016 15:45:28 +0100 (MET)
Received: from [192.168.178.33] (p5DEC2FCB.dip0.t-ipconnect.de [93.236.47.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 0D7A1D9304; Mon, 5 Dec 2016 15:45:28 +0100 (MET)
From: =?utf-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Message-Id: <ED6BB5D0-3A7F-481C-860D-E9E9BEC0DD39@tik.ee.ethz.ch>
Date: Mon, 5 Dec 2016 15:45:27 +0100
To: spud <spud@ietf.org>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/3Wdonyajn2O45HF0L-8iK8s3DbY>
Cc: plus@ietf.org, Brian Trammell <ietf@trammell.ch>
Subject: [Spud] New PLUS mailing list, side meeting and future steps
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: Mon, 05 Dec 2016 14:55:21 -0000

Hi all,

as previously announced on this list, we had a side meeting on PLUS at IETF-97. We had about 20 people attending and showing continued interest in working in this space. The discussion was mostly centered around draft-hardie-path-signals, which describes the concept of path signals as currently used by on-path devices; as well as draft-trammell-plus-statefulness, which describes a transport-independent state machine for on-path state management, the basis for any flow-based path signaling.

There was detailed discussion on the state machine as proposed in the -00 version of the draft starting from the need for a clear definition of what a stateful middlebox is, and expectations about the deployment of such middleboxes. It was further noted that for each signal that is exposed to a middlebox, a clear benefit must be shown. This further led to more discuss about the need and use of the stop/close signal and if it would be needed to also have cancel-stop signal if the close signal was detected by the receiver to be spoofed. This discussion is on-going, and related to current discussion on the quic list.

We have submitted a revision of draft-trammell-plus-statefulness has been published, based mainly on discussion after the side meeting. See:

https://datatracker.ietf.org/doc/draft-trammell-plus-statefulness/

Based on such a basic mechanism for state management, there was interest in using PLUS mechanisms for time-out exposure to optimize keep-alive traffic for mobile devices as well as providing input for network troubleshooting in a transport-independent way. To allow for future experimentation, the next step is to write a specification that describes the assumed wire image. There was interest in participating in this work from several attendees as well as a request for providing middlebox guidelines on how to interpret and use such a transport-independent wire image.

While the work on these approaches are continuing, we did not decide on any concrete plans for another attempt to start a working group in the IETF (e.g. having a BoF in the near future). With this mail, we would like to move future discussion over to the plus@ietf.org mailing list. This new mailing list is intended to be used for work and discussion on path layer signaling as indicated by the mailing list description:

https://www.ietf.org/mailman/listinfo/plus

If you are continuously interested in this work, please subscript to the plus list. We will close the spud list as we see the spud experiment on examining the tussle between in-network assumptions and stack evolution as started at the IAB SEMI workshop as finished, moving forward to concrete experimentation starting from basic in-network state management. We will announce new work and updates on the plus list only. Please feel free to use the plus list for any discussion related to path signaling!

Mirja and Brian