From nobody Mon Dec 5 06:55:23 2016 Return-Path: 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?= 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: Date: Mon, 5 Dec 2016 15:45:27 +0100 To: spud X-Mailer: Apple Mail (2.3251) Archived-At: Cc: plus@ietf.org, Brian Trammell 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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