Re: [multipathtcp] Socket API for MPTCP

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Sun, 10 July 2016 12:18 UTC

Return-Path: <olivier.bonaventure@uclouvain.be>
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 59B9912D162 for <multipathtcp@ietfa.amsl.com>; Sun, 10 Jul 2016 05:18:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level:
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be
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 8JYT5A8ACgro for <multipathtcp@ietfa.amsl.com>; Sun, 10 Jul 2016 05:18:42 -0700 (PDT)
Received: from smtp1.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA3412D15E for <multipathtcp@ietf.org>; Sun, 10 Jul 2016 05:18:41 -0700 (PDT)
Received: from mbpobo.local (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 9B00D67DA66; Sun, 10 Jul 2016 14:18:33 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.2 smtp1.sgsi.ucl.ac.be 9B00D67DA66
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1468153113; bh=GMGZqcvbbdVV+1irDmz4zrYfJGq7d7n+geia4+U9thY=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=itk0bSXoEJQFHh9ZHZwewOc7SRSfLo3k88sR7jRPn0CmEhoMgbeatdYyEI+EUm66f g4xvdnLe2c0MEhOearAzk8wjeSL+AMVy3cC57YtC5ILIV0ljmQCaX1BYjSPh4jXn2A tFBv2U7bwLZ1EkH4+3H9c49o2K9GLsAV2MrLuadE=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-1
References: <13734f09-4c78-06eb-7201-8f125097a5e8@uclouvain.be> <8760sdhgam.wl-jch@pps.univ-paris-diderot.fr>
To: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <80651913-f4fd-f439-0661-518115339a42@uclouvain.be>
Date: Sun, 10 Jul 2016 14:18:33 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <8760sdhgam.wl-jch@pps.univ-paris-diderot.fr>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-Information:
X-SGSI-MailScanner-ID: 9B00D67DA66.A27A6
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: olivier.bonaventure@uclouvain.be
X-SGSI-Spam-Status: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/r3zry1oCqM4s-x_L-02x7G3b7tw>
Cc: multipathtcp <multipathtcp@ietf.org>, "<mptcp-dev@listes.uclouvain.be>" <mptcp-dev@listes.uclouvain.be>
Subject: Re: [multipathtcp] Socket API for MPTCP
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Olivier.Bonaventure@uclouvain.be
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: Sun, 10 Jul 2016 12:18:43 -0000

Juliusz,
>
> I've only had a quick look at the draft, and haven't read the paper, so
> I could get this wrong.
>
> I don't see a way to receive asynchronous notifications of subflow
> creation and destruction.  If my application is using a select-based event
> loop, there is apparently no way to request that the select should be
> interrupted when a new flow is created.
>
> Is that correct?

The first draft does not yet describe how to support notifications. 
Benjamin is finalising the implementation of these notifications, 
currently on top of recvmsg and sendmsg. We will then look at select. 
These notifications will be documented in the next version of the draft.



Olivier