Re: [multipathtcp] MPTCP carrying UDP

Christoph Paasch <cpaasch@apple.com> Tue, 15 November 2016 17:22 UTC

Return-Path: <cpaasch@apple.com>
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 C2DD0129572 for <multipathtcp@ietfa.amsl.com>; Tue, 15 Nov 2016 09:22:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.799
X-Spam-Level:
X-Spam-Status: No, score=-5.799 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_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 DJXKp2MOCw2W for <multipathtcp@ietfa.amsl.com>; Tue, 15 Nov 2016 09:22:01 -0800 (PST)
Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (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 F2CC4128E18 for <multipathtcp@ietf.org>; Tue, 15 Nov 2016 09:22:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1479230520; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=abtZuic8fDvlKUt+VXrN/Ht9YvQQmqEFjy/UN3WfpYI=; b=yRisd/IOQd4pL4H/vybARR62SPjs42sfYH+/6cFbrNJXLUWLzxps5+7ZfsjvwC+3 jJrQdbYmmFft/brwwvV0T7x5nVA537oOAbFeIkbqhLOgW5YudLGOkcXLD3jriObg iWfQxn58js0xbQkUyzcCKPvl+z3dhQ769h9u65okq+vgq666jlbVMtOD9sv9yn0x Grv0lRkx/Gcxyvgicpe/wdaVts5IL9Y5IpuUf9Kpi7pt815908vwUiQHdjr2q9pf SAFOuRNZgW9He9siwHTfvMy2J4vSQS31QKoK1eeQKqtTfEmm8cBEOxbXW+oTMRTI Uw1r8+E9EBERgfeESLdnQw==;
Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 08.41.16908.8344B285; Tue, 15 Nov 2016 09:22:00 -0800 (PST)
X-AuditID: 11973e15-8ada39a00000420c-b3-582b4438327e
Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by relay6.apple.com (Apple SCV relay) with SMTP id 2B.EC.23613.8344B285; Tue, 15 Nov 2016 09:22:00 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-disposition: inline
Content-type: text/plain; charset=utf-8
Received: from localhost ([17.149.239.87]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OGP00CIB1KOBV80@nwk-mmpp-sz13.apple.com>; Tue, 15 Nov 2016 09:22:00 -0800 (PST)
Sender: cpaasch@apple.com
Date: Tue, 15 Nov 2016 09:21:59 -0800
From: Christoph Paasch <cpaasch@apple.com>
To: mohamed.boucadair@orange.com
Message-id: <20161115172159.GX4269@Chimay.local>
References: <4d11a19b2b6644848ce79f55cdbd6ab5@rew09926dag03b.domain1.systemhost.net> <787AE7BB302AE849A7480A190F8B933009DB40D0@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
In-reply-to: <787AE7BB302AE849A7480A190F8B933009DB40D0@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUi2FAYpWvhoh1hcOmFrMXKcyuYLd423GOy OPz2KbvF59XX2SyWrV3BaLFq5zM2BzaPti+TmTx+fb3K5rFz1l12jyVLfjJ5tDw7yeZxt2sm cwBbFJdNSmpOZllqkb5dAlfG9KdzWAomeVasm3eZuYHxoU0XIyeHhICJxKM3Txi7GLk4hAT2 MkosW/uAHSZxe8EZNojEIUaJu3c+sIIkeAUEJX5MvsfSxcjBwSwgL3HkUjZImFlAWuLR3xns EGF1iSlTciFafzFKtF06B9YqLCAp0X3nDjOIzSKgKvH+xVo2EJtNQEvi7e12sBoRAQWJfW39 LCDNzAL9TBKdnxYwgwwVFtCTuLixGuIEA4kfB7tYIRasY5S4eq8RbCinQIpE+8tHLCC2qICy xN/D98AGSQj8Z5P4tu4TywRGkVlIfpiF8MMsJD/MQvhhASPLKkah3MTMHN3MPDO9xIKCnFS9 5PzcTYygyJpuJ7qD8cwqq0OMAhyMSjy8HqraEUKsiWXFlbmHGKU5WJTEeVmtgEIC6Yklqdmp qQWpRfFFpTmpxYcYmTg4pRoYJYoY2p5YbOaezh+0YVpN77YNJ++diVu2Oev/ec+eBxFuV77v ZA930j/Buemzzv7txbMzDM/cu/a2z1Isz3/v167m2MrVO19NMS04kBrr/dm0pcsxbUo4R+mp iYK2P86vYeKU2XFE65Dj/zwRy3PL9n2NCWRs7mZ6840prdrdL/b/ki2xOnJrlFiKMxINtZiL ihMBBJBs140CAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsUi2FB8Q9fCRTvC4OMSMYuV51YwW7xtuMdk cfjtU3aLz6uvs1ksW7uC0WLVzmdsDmwebV8mM3n8+nqVzWPnrLvsHkuW/GTyaHl2ks3jbtdM 5gC2KC6blNSczLLUIn27BK6M6U/nsBRM8qxYN+8ycwPjQ5suRk4OCQETidsLzrBB2GISF+6t B7K5OIQEDjFK3L3zgRUkwSsgKPFj8j2WLkYODmYBeYkjl7JBwswC0hKP/s5ghwirS0yZkgvR +otRou3SObBWYQFJie47d5hBbBYBVYn3L9aC7WIT0JJ4e7sdrEZEQEFiX1s/C0gzs0A/k0Tn pwXMIEOFBfQkLm6shjjBQOLHwS5WiAXrGCWu3msEG8opkCLR/vIRC4gtKqAs8ffwPZYJjEKz kJw9C+HsWUjOnoVw9gJGllWMAkWpOYmVZnqJBQU5qXrJ+bmbGMERUhi1g7FhudUhRgEORiUe Xg9V7Qgh1sSy4spcYBBxMCuJ8PJbAoV4UxIrq1KL8uOLSnNSiw8xJgP9O5FZSjQ5Hxi9eSXx hiYmBibGxmbGxuYm5qQJK4nzmotqRQgJpCeWpGanphakFsFsYeLglGpgzOQ05dx37U/hfLfr f1e9YjWovrC2zu17nr7vq8JA8fn5WbMvsceZNrKav9rUzvi0XOtsvGlC/8UbebrHd4QeKf1S +EP4mP1Hq/WuvnnTZ6aFCP+fXv1ogzSDvFDZf6mzRT/NExqbdu37cUF61YXQ+yEWrsztV89G TeHtKlo45+OEm1emhzrNU2Ipzkg01GIuKk4EAGtZuyXUAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/CynxBWT1PW3hi9Pq1I-CKguYAJM>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>, "Markus.Brunner3@swisscom.com" <Markus.Brunner3@swisscom.com>
Subject: Re: [multipathtcp] MPTCP carrying UDP
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 17:22:04 -0000

On 15/11/16 - 12:40:01, mohamed.boucadair@orange.com wrote:
> Re-,
> 
> I have one comment about the target applications: QUIC is definitely one.
> 
> For the VoIP case (RTP to be more accurate), there is already a candidate solution: Multipath RTP (https://tools.ietf.org/html/draft-ietf-avtcore-mprtp-03).
> 
> I don’t have results to share because we are in a chicken/egg situation: implementers are asking for a stable specification to play with.

I don't buy this argument. Implementors can build a prototype to feed
information/feedback into the standardization process.


Christoph

> 
> Cheers,
> Med
> 
> De : philip.eardley@bt.com [mailto:philip.eardley@bt.com]
> Envoyé : mardi 15 novembre 2016 12:51
> À : robert.skog@ericsson.com; BOUCADAIR Mohamed IMT/OLN; Markus.Brunner3@swisscom.com; alan.ford@gmail.com
> Cc : multipathtcp@ietf.org
> Objet : MPTCP carrying UDP
> 
> (I changed the Subject line of the email)
> 
> Do people have any experimental results /experiences they could share of running UDP applications over MPTCP sub-flows?  Would be interested to hear about the issues. I guess VoIP and Quic would be the most interesting ones. Whether the experiments are with only one path being used at once, or multiple. etc
> 
> 
> 
> From: Robert Skog [mailto:robert.skog@ericsson.com]
> Sent: 15 November 2016 10:09
> To: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; Markus.Brunner3@swisscom.com<mailto:Markus.Brunner3@swisscom.com>; Eardley,PL,Philip,TUB8 R <philip.eardley@bt.com<mailto:philip.eardley@bt.com>>; alan.ford@gmail.com<mailto:alan.ford@gmail.com>
> Cc: multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>
> Subject: RE: [multipathtcp] Towards a Multipath TCP Proxy work item
> 
> +1
> We see a need to solve UDP in several places, so having a separate specification can help this moving forward.
> 
> Cheers,
> /Robert
> 
> From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>
> Sent: den 15 november 2016 09:57
> To: Markus.Brunner3@swisscom.com<mailto:Markus.Brunner3@swisscom.com>; philip.eardley@bt.com<mailto:philip.eardley@bt.com>; alan.ford@gmail.com<mailto:alan.ford@gmail.com>
> Cc: multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>
> Subject: Re: [multipathtcp] Towards a Multipath TCP Proxy work item
> 
> Hi Markus, all,
> 
> I’m on the same page that non-tcp traffic should be considered in scope. At least, the UDP case should be investigated. I remember there was interest in BA meeting about the UDP part (https://www.ietf.org/proceedings/95/minutes/minutes-95-mptcp).
> 
> An option I see is to consider advancing the use of MPTCP to convey UDP flows in a separate EXPERIMENTAL specification that will be cross-reviewed with other WGs (intarea, tsvwg). Having that base specification will help having interoperable implementations that will be used to carry experimentations.
> 
> Those experiments will help to determine whether the proposed solution is complex/simple, viable/non-viable, failed/successful, etc.
> 
> Let’s give it a try.
> 
> Cheers,
> Med
> 
> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de Markus.Brunner3@swisscom.com<mailto:Markus.Brunner3@swisscom.com>
> Envoyé : mardi 15 novembre 2016 08:58
> À : philip.eardley@bt.com<mailto:philip.eardley@bt.com>; alan.ford@gmail.com<mailto:alan.ford@gmail.com>
> Cc : multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>
> Objet : Re: [multipathtcp] Towards a Multipath TCP Proxy work item
> 
> Phil,
> 
> If you feel it would take too long and to be too complex to achieve in a reasonable timeframe, we are ok with excluding non-tcp traffic, however, for our total solution we do requires also non-tcp traffic to be sent over multiple paths. We could argue that we can use a different mechanisms specifically for UDP and other protocols, but it would be nice to have as single MPTCP-based solution. (my gut feeling is that we would need to replicate a lot of MPTCP scheduling features into a new mechanism).
> 
> Marcus
> 
> Von: multipathtcp <multipathtcp-bounces@ietf.org<mailto:multipathtcp-bounces@ietf.org>> im Auftrag von "philip.eardley@bt.com<mailto:philip.eardley@bt.com>" <philip.eardley@bt.com<mailto:philip.eardley@bt.com>>
> Datum: Montag, 14. November 2016 um 07:32
> An: "alan.ford@gmail.com<mailto:alan.ford@gmail.com>" <alan.ford@gmail.com<mailto:alan.ford@gmail.com>>
> Cc: "multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>" <multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>>
> Betreff: Re: [multipathtcp] Towards a Multipath TCP Proxy work item
> 
> 
> i think we should move beyond "exploring whether it would be useful".
> 
> 
> 
> i'd like us to assess proposed solutions. i think we should say this is what we're doing - at the moment we've had quite a lot of discussion about one proposal. we should give the chance for other proposals, and make the discussion more structured (what are the assessment criteria).
> 
> 
> 
> i also think we should explicitly exclude non-tcp traffic  (i think non-tcp traffic is too big a topic for our WG)
> 
> 
> 
> phil
> 
> 
> 
> 
> 
> ________________________________
> From: Alan Ford <alan.ford@gmail.com<mailto:alan.ford@gmail.com>>
> Sent: 14 November 2016 06:11
> To: Eardley,PL,Philip,TUB8 R
> Cc: multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>
> Subject: Re: [multipathtcp] Towards a Multipath TCP Proxy work item
> 
> I think this work item is achievable by simply removing references to “at least one end” from the existing charter item on the proxy. So the item would now read:
> 
> Finally, the working group will explore whether an MPTCP-aware
> middlebox would be useful. For example, potentially helping MPTCP’s
> incremental deployment by allowing only one end host to be MPTCP-enabled
> and the middlebox acts as an MPTCP proxy for the other end host, which runs
> TCP; and potentially helping some mobility scenarios, where the middle box
> acts as an anchor between two MPTCP-enabled hosts. Alternatively, neither
> end host could be MPTCP-enabled but a pair of proxies could work together to
> bring MPTCP benefits to such connections. The working group will detail what real
> problems an MPTCP-enabled middlebox might solve, how it would impact the
> Multipath TCP architecture (RFC6182), what proxy approach might be
> justified as compared against alternative solutions to the problems, and
> the likely feasibility of solving the technical and security issues.
> 
> In some ways, the two ended proxy work could even be seen as an extension of the previous operational experience work within this WG.
> 
> Regards,
> Alan
> 
> On 10 Nov 2016, at 19:17, philip.eardley@bt.com<mailto:philip.eardley@bt.com> wrote:
> 
> Hi,
> Perhaps this is speaking too soon, but it looks like the very active discussion is reaching some common understanding?
> 
> We’re trying to work out what a work item might look like, so would like to understand what assumptions we would make, eg about the scenario, & what common agreements we’d assume & restrictions on how the solution works. This seems important to frame work by WG. If possible we’d like discussion on these points to avoid getting into the fine details of one particular existing proposal.
> 
> What we’d appreciate is a summary of what the assumptions /understandings are about:
> •         The scenario (for instance: the MPTCP-enabled host knows the address of the proxy (eg through configuration); and it knows the address of the ‘legacy’ host it wants to communicate with)
> •         If any impact is already envisaged on the current MPTCP protocol’s fallback behaviour and coping with middleboxes
> •         If we can agree that the solution is based on a new MPTCP option
> •         If any impact is already envisaged on the current MPTCP protocol’s semantics (other than the new option) eg in terms of https://tools.ietf.org/html/rfc6824#section-4
> •         If any impact is already envisaged on TCP’s semantics, or any mods are needed, or assumptions about its behaviour, etc
> •         If any impact is already envisaged on other existing transport protocol’s semantics (presuming people still would like non-TCP in scope?)
> •         Anything else that you think is needed in order to frame the work item
> 
> It may be clearer to do this for the two use cases (single-ended proxy, ie where only one host is MPTCP-enabled; and double-ended proxy, ie where neither host is MPTCP-enabled).
> 
> This may seem like a long list, but most of the answers can be “none” – we’ll end up with just a short paragraph or a few bullets in the charter.
> 
> We’d also have to work out interactions with non-MPTCP WGs, but Mirja and IESG will probably want the main input on this.
> 
> Thanks
> Phil & Yoshi
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>
> https://www.ietf.org/mailman/listinfo/multipathtcp
> 

> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp