Re: [multipathtcp] Adding a new work item on MPTCP API

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Tue, 15 November 2016 15:23 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882F11293DB for <multipathtcp@ietfa.amsl.com>; Tue, 15 Nov 2016 07:23:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level:
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-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 IiVMeKGu9dOH for <multipathtcp@ietfa.amsl.com>; Tue, 15 Nov 2016 07:23:36 -0800 (PST)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC56412007C for <multipathtcp@ietf.org>; Tue, 15 Nov 2016 07:23:35 -0800 (PST)
Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com [209.85.213.42]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E1C152786F2 for <multipathtcp@ietf.org>; Wed, 16 Nov 2016 00:23:33 +0900 (JST)
Received: by mail-vk0-f42.google.com with SMTP id x186so91336963vkd.1 for <multipathtcp@ietf.org>; Tue, 15 Nov 2016 07:23:33 -0800 (PST)
X-Gm-Message-State: ABUngvc3H64NUK3Zgx1UEPuoLfMTxi5AwQkPQ2Z3ifJf7XiP+C2SSCZvMk9Ooj/gwkdQAikfFhMf3yFjjefzXg==
X-Received: by 10.31.86.132 with SMTP id k126mr13567037vkb.11.1479223412261; Tue, 15 Nov 2016 07:23:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.80.232 with HTTP; Tue, 15 Nov 2016 07:23:31 -0800 (PST)
In-Reply-To: <655C07320163294895BBADA28372AF5D48B79205@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References: <0a0d2a248fac4616ac795c579d996be8@rew09926dag03b.domain1.systemhost.net> <20161113073136.GF4269@Chimay.local> <495a3fd8-e83d-29f6-5612-bea5222a0d38@uclouvain.be> <1479100195639.46263@bt.com> <655C07320163294895BBADA28372AF5D48B79205@FR712WXCHMBA15.zeu.alcatel-lucent.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Tue, 15 Nov 2016 07:23:31 -0800
X-Gmail-Original-Message-ID: <CAO249yd_f21S8UcGrBJoDvEoKNnQ4B9Z1HoN0fmnME9wddDpsA@mail.gmail.com>
Message-ID: <CAO249yd_f21S8UcGrBJoDvEoKNnQ4B9Z1HoN0fmnME9wddDpsA@mail.gmail.com>
To: "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/R0IoqNqmyLehwiLWO_XrN5Mv2mw>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] Adding a new work item on MPTCP API
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Nov 2016 15:23:38 -0000

BTW, just FYI.. the texts I showed during the meeting were a slightly
different and doesn't have socket operation term.
I thought about it the night before the meeting, but couldn't come up
with other words. So, I decided to omit it as I thought this part is
probably not very crucial. But, of course, better terms are welcome.

https://www.ietf.org/proceedings/97/slides/slides-97-mptcp-chair-slide-01.pdf
--
Yoshi

On Sun, Nov 13, 2016 at 10:53 PM, Scharf, Michael (Nokia - DE)
<michael.scharf@nokia.com> wrote:
> As far as I recall, I think the term "socket operation" was intentionally used instead of "socket option", since it was considered to be applicable to any TCP API, e.g., also the APIs used by high-level programming languages such as Java.
>
> The feedback was that the term "socket option" is not applicable to all TCP stacks. And even on TCP stacks that use the socket interface, many applications may have no access to socket options since they use a more abstract API (e.g., a library). The objective of RFC 6897 was to apply to all potential TCP stacks.
>
> Possibly better terms can be found.
>
> Michael
>
>> -----Original Message-----
>> From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of
>> philip.eardley@bt.com
>> Sent: Monday, November 14, 2016 6:10 AM
>> To: fabien.duchene@uclouvain.be; multipathtcp@ietf.org
>> Subject: Re: [multipathtcp] Adding a new work item on MPTCP API
>>
>> re socket operations.
>> this is the term used in https://tools.ietf.org/html/rfc6897#section-5.3
>> happy to use whatever term is clearest - operations, options or sometihing
>> else!
>> phil
>> ________________________________________
>> From: multipathtcp <multipathtcp-bounces@ietf.org> on behalf of Fabien Duchêne
>> <fabien.duchene@uclouvain.be>
>> Sent: 14 November 2016 02:03
>> To: multipathtcp@ietf.org
>> Subject: Re: [multipathtcp] Adding a new work item on MPTCP API
>>
>> Hello,
>>
>>
>> On 11/13/2016 08:31 AM, Christoph Paasch wrote:
>> > Hello,
>> >
>> > On 09/11/16 - 10:21:42, philip.eardley@bt.com wrote:
>> >> Following the earlier discussion, there is support to add a charter item as
>> follows:
>> >> <<RFC6897 defined an optional, basic application interface for MPTCP-aware
>> applications, including a set of socket operations. Now there is more
>> experience of how MPTCP is being used, the WG will re-visit this work, and
>> consider adding more advanced socket operations. The document will be
>> Informational.>>
>> >> If you disagree with this being added, or suggest some mod to this item,
>> please say.
>> > I support this work as well.
>> >
>> > But, I also agree with Mirja's comment that "socket operations" is not a
>> > well-defined term. I guess, what has been meant was "socket options" - the
>> > ones that are available in many operating systems.
>> >
>> > I think the API should not limit itself to a specific way on how to
>> > configure the stack (e.g., through socket-options, ioctl, netlink,...).
>> > But rather be agnostic as to the technical details on how the higher
>> > layer configures/controls the MPTCP-stack.
>> >
>>
>> I support this work and I agree with Christoph and Mirja.
>> > Christoph
>> >
>>
>> Cheers,
>>
>> Fabien
>>
>>
>> _______________________________________________
>> multipathtcp mailing list
>> multipathtcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/multipathtcp
>>
>> _______________________________________________
>> multipathtcp mailing list
>> multipathtcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/multipathtcp
>
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp