[Taps] New Version Notification for draft-tiesel-taps-socketintents-01.txt

"Philipp S. Tiesel" <phils@in-panik.de> Mon, 30 October 2017 20:16 UTC

Return-Path: <phils@in-panik.de>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C914313F554 for <taps@ietfa.amsl.com>; Mon, 30 Oct 2017 13:16:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 TuzDumjzGLaM for <taps@ietfa.amsl.com>; Mon, 30 Oct 2017 13:16:22 -0700 (PDT)
Received: from einhorn-mail.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) (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 2CC57139478 for <taps@ietf.org>; Mon, 30 Oct 2017 13:16:22 -0700 (PDT)
X-Envelope-From: phils@in-panik.de
X-Envelope-To: <taps@ietf.org>
Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v9UKG0mX016911 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <taps@ietf.org>; Mon, 30 Oct 2017 21:16:00 +0100
Received: from [2001:bf0:c801:101:c5c2:5a20:ca4:2e26] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <phils@in-panik.de>) id 1e9GT6-0005WU-St for taps@ietf.org; Mon, 30 Oct 2017 21:15:32 +0100
From: "Philipp S. Tiesel" <phils@in-panik.de>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8B2C9D01-84F9-4A12-8DF5-1536332AD0D0"
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Message-Id: <06DE461E-D289-4B6C-AE37-28098BF7244F@in-panik.de>
References: <150922047627.2738.7553047120989518171.idtracker@ietfa.amsl.com>
To: taps WG <taps@ietf.org>
Date: Mon, 30 Oct 2017 21:15:57 +0100
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/gqw-qSbdH5YTeyaE4OcQf6CKTYE>
Subject: [Taps] New Version Notification for draft-tiesel-taps-socketintents-01.txt
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Oct 2017 20:16:25 -0000

Hi,

We’ve updated our Internet Draft on Socket Intents.

Socket Intents are a generic mechanism for applications to express non-requirement performance preferences, like optimize for bandwidth or latency, and applications’ knowledge, like expected bandwidth usage.   
Socket Intents are specified in a portable way and can be added to any transport API, including Post Sockets, the NEAT API or, with limitations, to regular BSD sockets.

With this second version, I want to raise a few questions.

 - Are Socket Intents easy enough?

 - Is the structure of Socket Intent Types sufficient to express
   all anticipated future  non-requirement performance preferences
   and application knowledge?

 - What Socket Intent Types / kinds of information are missing?

 - Does the current abstract definition of Socket Intents
   fit the way the IETF specifies abstract APIs?

We are looking forward to an active discussion here and in Singapore and hope that we find a way to push Socket Intents forward.

AVE!
  Philipp S. Tiesel / phils…

> Begin forwarded message:
> 
> A new version of I-D, draft-tiesel-taps-socketintents-01.txt
> has been successfully submitted by Philipp S. Tiesel and posted to the
> IETF repository.
> 
> Name:		draft-tiesel-taps-socketintents
> Revision:	01
> Title:		Socket Intents
> Document date:	2017-10-27
> Group:		Individual Submission
> Pages:		15
> URL:            https://www.ietf.org/internet-drafts/draft-tiesel-taps-socketintents-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-tiesel-taps-socketintents/
> Htmlized:       https://tools.ietf.org/html/draft-tiesel-taps-socketintents-01
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-tiesel-taps-socketintents-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-tiesel-taps-socketintents-01
> 
> Abstract:
>   This document outlines Socket Intents, a concept that allows
>   applications to share their knowledge about upcoming communication
>   and express their performance preferences in a generic, intuitive
>   and, portable way.  Using Socket Intents, an application can express
>   what it knows, assumes, expects, or wants regarding its network
>   communication.  The information provided by Socket Intents can be
>   used by the network stack to optimize communication in a best-effort
>   way.
> 
>   Socket Intent can be used to stem against the complexity of
>   exploiting transport diversity, e.g., to automate the choice among
>   multiple paths, provisioning domains or protocols.  By shifting this
>   complexity from the application developer to the operating system, it
>   enables the use of these transport features to a wider range of
>   applications.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>