From miroslav.popovic@epfl.ch Mon Jun 6 09:57:37 2011 Return-Path: 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 ED98211E819F for ; Mon, 6 Jun 2011 09:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGtHfRBJ81i9 for ; Mon, 6 Jun 2011 09:57:37 -0700 (PDT) Received: from smtp0.epfl.ch (smtp0.epfl.ch [128.178.224.219]) by ietfa.amsl.com (Postfix) with SMTP id ED37611E8179 for ; Mon, 6 Jun 2011 09:57:36 -0700 (PDT) Received: (qmail 1473 invoked by uid 107); 6 Jun 2011 16:57:33 -0000 X-Virus-Scanned: ClamAV Received: from slb-nat-128-178-224-29.epfl.ch (HELO discarded) (192.26.45.29) by mail.epfl.ch (AngelmatoPhylax SMTP proxy) with ESMTP; Mon, 06 Jun 2011 18:57:33 +0200 Received: from REXM3.intranet.epfl.ch ([fe80::a5ad:6339:48a:ed54]) by ewa5.intranet.epfl.ch ([2002:80b2:e01d::80b2:e01d]) with mapi id 14.01.0289.001; Mon, 6 Jun 2011 18:57:33 +0200 From: Popovic Miroslav To: "multipathtcp@ietf.org" Thread-Topic: Question about receiving window Thread-Index: AcwkatOknVWOyn5zRGGJFGq4elDQvw== Date: Mon, 6 Jun 2011 16:57:32 +0000 Message-ID: Accept-Language: en-US, fr-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.178.151.96] Content-Type: multipart/alternative; boundary="_000_D4FD16C4FE1EDA4BBF3C1CC556EB6C1847D8AF5DREXM3intranetep_" MIME-Version: 1.0 Subject: [multipathtcp] Question about receiving window X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 16:57:38 -0000 --_000_D4FD16C4FE1EDA4BBF3C1CC556EB6C1847D8AF5DREXM3intranetep_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, We are doing some experiments with MPTCP and we have a question about it. We could not clearly find in the MPTCP documents what is the default size f= or receiving window and whether Window Scaling is used or not. We would ap= preciate any help concerning this. Thanks, Miroslav Popovic --_000_D4FD16C4FE1EDA4BBF3C1CC556EB6C1847D8AF5DREXM3intranetep_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

We are doing some experiments w= ith MPTCP and we have a question about it.

 

We could not clearly find in th= e MPTCP documents what is the default size for receiving window and whether= Window Scaling is used or not.  We would appreciate any help concerni= ng this.

 

Thanks,

Miroslav Popovic

 

--_000_D4FD16C4FE1EDA4BBF3C1CC556EB6C1847D8AF5DREXM3intranetep_-- From internet-drafts@ietf.org Tue Jun 7 06:35:15 2011 Return-Path: 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 80E7B21F848F; Tue, 7 Jun 2011 06:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVeCfDEru-Hp; Tue, 7 Jun 2011 06:35:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E638F21F843F; Tue, 7 Jun 2011 06:35:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110607133514.16053.61359.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2011 06:35:14 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-api-02.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 13:35:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multipath TCP Working Group of the IE= TF. Title : MPTCP Application Interface Considerations Author(s) : Michael Scharf Alan Ford Filename : draft-ietf-mptcp-api-02.txt Pages : 28 Date : 2011-06-07 Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface for MPTCP-aware applications that provides access to multipath address information and a level of control equivalent to regular TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-api-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-api-02.txt From Michael.Scharf@alcatel-lucent.com Tue Jun 7 06:40:54 2011 Return-Path: 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 54FB521F84E9 for ; Tue, 7 Jun 2011 06:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RH4uoUmyW9Oa for ; Tue, 7 Jun 2011 06:40:53 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDE321F84B3 for ; Tue, 7 Jun 2011 06:40:52 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p57DepDP031299; Tue, 7 Jun 2011 15:40:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2011 15:40:48 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0607B393@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-mptcp-api-02 Thread-Index: AcwlF9xTO8V8rIIcTYynk/IVmsTVJgAADLfA From: "SCHARF, Michael" To: "mptcp" X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Subject: [multipathtcp] draft-ietf-mptcp-api-02 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 13:40:54 -0000 Dear all, we submitted an update of the API draft that addresses the review comments from Javier Ubillos and Michael Tuexen (thanks again!). Please let us know if you have any comments before it gets last called. Thanks Michael -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Tuesday, June 07, 2011 3:35 PM To: i-d-announce@ietf.org Cc: multipathtcp@ietf.org Subject: I-D Action: draft-ietf-mptcp-api-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multipath TCP Working Group of the IETF. Title : MPTCP Application Interface Considerations Author(s) : Michael Scharf Alan Ford Filename : draft-ietf-mptcp-api-02.txt Pages : 28 Date : 2011-06-07 Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface for MPTCP-aware applications that provides access to multipath address information and a level of control equivalent to regular TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-api-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-api-02.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From yoshifumi.nishida@gmail.com Wed Jun 15 02:02:29 2011 Return-Path: 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 314AA1F0C40 for ; Wed, 15 Jun 2011 02:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8L01tkfBfLp for ; Wed, 15 Jun 2011 02:02:28 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF5931F0C35 for ; Wed, 15 Jun 2011 02:02:28 -0700 (PDT) Received: by iwn39 with SMTP id 39so160051iwn.31 for ; Wed, 15 Jun 2011 02:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3SU3p3Z0DUomIXJvIBW8js0TooUfVVE7XMvr1/X/a7w=; b=tHiCN77/SjiomU7vMsk5D2B3gMaxgDMDShEfpWCOKemhxMwdsPM0SW/+qP/2qAEjGR W48vwX9FvXJtI7fnxICQcyvNBdgn2XMv4Q3YYtnJFFYnLkW9ySgVGO5m8RZB59+iCNER 4s/s/G2WrcrsUFF8yh5tshw6YHQAWtjP/hqjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=snkA4lN0SuNOUjIbWkikZdRzxnk8Lb8cHVLSIxS0r2izfS7X18mrDgPRg4X8p9MEWx +g40pn0r0jf8lU3QEJ1USOkUv01Vb71phhA13OTQEcmGQXlmkesCayWyihjyMqNVoMW1 +giF37qCZ0Llix+ofbTf88TXPNGi6SKnsTu+k= MIME-Version: 1.0 Received: by 10.231.119.216 with SMTP id a24mr256954ibr.58.1308128547482; Wed, 15 Jun 2011 02:02:27 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.251.198 with HTTP; Wed, 15 Jun 2011 02:02:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Jun 2011 02:02:27 -0700 X-Google-Sender-Auth: IDJ2wm_tkhOu525SC0UgCGN8nek Message-ID: From: Yoshifumi Nishida To: Popovic Miroslav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Question about receiving window X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 09:02:29 -0000 Hi Popovic, 2011/6/6 Popovic Miroslav : > We could not clearly find in the MPTCP documents what is the default size > for receiving window and whether Window Scaling is used or not.=A0 We wou= ld > appreciate any help concerning this. I think these are implementation-specific questions. But, I think window scaling is recommended to be used. You might want to check section 3.3.4 of draft-ietf-mptcp-multiaddressed-03 for receiver buffer size. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From internet-drafts@ietf.org Wed Jun 15 05:58:17 2011 Return-Path: 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 7EC6A11E8117; Wed, 15 Jun 2011 05:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hIwBqbH9i-4; Wed, 15 Jun 2011 05:58:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B6511E80F0; Wed, 15 Jun 2011 05:58:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110615125817.10824.68111.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2011 05:58:17 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-congestion-04.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 12:58:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multipath TCP Working Group of the IE= TF. Title : Coupled Congestion Control for Multipath Transport Proto= cols Author(s) : Costin Raiciu Mark Handley Damon Wischik Filename : draft-ietf-mptcp-congestion-04.txt Pages : 12 Date : 2011-06-15 Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP. New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, hence achieving resource pooling. This would increase the overall efficiency of the network and also its robustness to failure. This document presents a congestion control algorithm which couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-congestion-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-congestion-04.txt From andrewmcgr@gmail.com Wed Jun 15 15:57:39 2011 Return-Path: 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 1F86F11E80C7 for ; Wed, 15 Jun 2011 15:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQO-Z89utld7 for ; Wed, 15 Jun 2011 15:57:38 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F49611E80A0 for ; Wed, 15 Jun 2011 15:57:38 -0700 (PDT) Received: by pzk5 with SMTP id 5so773681pzk.31 for ; Wed, 15 Jun 2011 15:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=ETelRsReBzCX7UK9CD1zFw8KaGcc0HetM7zlB9DluT0=; b=RWeOj3CtF8VS560Nuc6wi77C/i78slSr+K/AVuwiaGwgO6GFO3XD5IHJs5HTvYsZqO I6LuDeG4+tS+NMjuhdTULEOmxMAh0JycgBGqfUwTolCqjvKZLWztrPxNvRSgg46uAp9D h/VMZx9D6t8B05PuogEWC/xs+xCT46KkwXmzE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=t7J8go8kwoL39C9G/25nLtpbYwpTrvwsQ5QQSb6jPe6MX65MKAP/UT6RreVpFte/lK kY5zhPI+wvwP4asMRCEzLO6mE1p9KOs0UKrxTP6kA74rUSvJDcQnlJrfh06CKTNLhP1x LIkiWQN+1O3lEMM9ZOoFKPjy5/fiNPR/8nlUk= Received: by 10.68.33.70 with SMTP id p6mr150554pbi.480.1308178657897; Wed, 15 Jun 2011 15:57:37 -0700 (PDT) Received: from andrewm-lo.ws.alliedtelesyn.co.nz (gate1.alliedtelesyn.co.nz [202.49.72.36]) by mx.google.com with ESMTPS id v6sm479026pbh.54.2011.06.15.15.57.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Jun 2011 15:57:36 -0700 (PDT) From: Andrew McGregor Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Jun 2011 10:57:31 +1200 Message-Id: <0A2BA2A4-A3AE-450B-8061-9B624CD4741B@gmail.com> To: Yoshifumi Nishida , Philip Eardley , Alan Ford , Costin Raiciu , Mark Handley , Olivier Bonaventure , multipathtcp@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [multipathtcp] Review of draft-ietf-mptcp-multiaddressed-03 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 22:57:39 -0000 I finally got to do this review, what with earthquakes and = reorganisations it was rather a mission. I think this document is in good shape, most of my comments are little = textual items rather than substantive issues needing clarifications. Three substantive issues first: Section 3.3.1, page 21: Note that checksumming relies on the TCP subflow containing contiguous data, and therefore a TCP subflow MUST NOT use the Urgent Pointer to interrupt an existing mapping. Further note, however, that if Urgent data is received on a subflow, it SHOULD be mapped to the data sequence space and delivered to the application analogous to Urgent data in regular TCP. Once you receive urgent data, the world is no longer safe for the = checksum... so something needs to be said about what happens next after = the urgent data is delivered. RST everything and require new joins? Section 3.3.1, page 22: Data sequence numbers are always 64-bit quantities, and MUST be maintained as such in implementations. At the end of this paragraph, perhaps add: An implementation MAY choose = to send 32 or 64 bit Data Sequence Numbers independently for each = packet. This is implicitly allowed by Appendix A, but I think it should be = explicit in this section. Section 3.4.1, page 33: A host that receives an ADD_ADDR but finds a connection setup to that address is unsuccessful SHOULD NOT perform further connection attempts to this address for this connection. A sender that wants to trigger a new incoming connection attempt on a previously advertised address can therefore refresh ADD_ADDR information by sending the option again. This is inconsistent with section 3.7.3, page 39: =46rom the connection initiator's point of view, if an MP_JOIN fails, it SHOULD NOT attempt to connect to the same IP address during the lifetime of the connection, unless the other host refreshes the information with a REMOVE_ADDR and then an ADD_ADDR for the same address. Should this read: it SHOULD NOT attempt to connect to the same IP = address and port number An MP_JOIN may fail if the initiator is behind a NAT and is not aware = that it joined from the same IP address, so a join to the same remote = port number fails where a join to a different port would succeed. = Conversely, it may be desirable not to allow this situation to initiate = multiple subflows. And in any case, these two paragraphs should be consistent with each = other as to how the address should be refreshed. Nits: Section 2, third paragraph, page 8: "The client are server keys" -> "The = client and server keys". Also, I find this sentence unweildly, but I'm = not sure how it could be reworded. Section 2, third paragraph, page 8: "a 32 bits token" -> "a 32 bit = token". This same error occurs many times in the remainder of the = document, sometimes with and without a hyphen. Some consistency would be = good. Section 2, fourth paragraph, page 8: "The MP_JOIN option contains the = server's token that uniquely identifies the MPTCP connection to which = the subflow must be associated and a random number." -> "The MP_JOIN = option contains the server's token and a random number." since the = function of the token was described in the previous paragraph. Section 2, last paragraph, page 9: "possibly out-of-sequence over", add = a comma after sequence Section 3.1, page 11: remove "it just means that", since this doesn't = add anything Section 3.3.1, page 22: "and an unmapped data" -> "and any unmapped = data" Section 3.4.1, page 32: "and ordering it will not break" -> "and = ordering will not break" Bullet lists at the end of Section 6: each bullet has a : after the = subject of the first sentence... this seems silly, it just breaks the = reader's flow. Appendix A: "24 bytes (for Join) - both of which" -> "24 bytes (for = Join), both of which"= From prvs=21485fedb3=alan.ford@roke.co.uk Thu Jun 16 01:50:15 2011 Return-Path: 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 5E2FC11E8104 for ; Thu, 16 Jun 2011 01:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5UeF3xvPVUu for ; Thu, 16 Jun 2011 01:50:14 -0700 (PDT) Received: from gse-mta-29.emailfiltering.com (gse-mta-29-tx.emailfiltering.com [194.116.198.160]) by ietfa.amsl.com (Postfix) with ESMTP id 53B8D11E807B for ; Thu, 16 Jun 2011 01:50:14 -0700 (PDT) Received: from salt-ext.roke.co.uk ([109.207.29.2]) by gse-mta-29.emailfiltering.com with emfmta (version 4.8.1.33) vanilla id 435566656 for nishida@sfc.wide.ad.jp; 76f47415cebd4a7e; Thu, 16 Jun 2011 09:50:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Jun 2011 09:50:06 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680D0E23DB@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <0A2BA2A4-A3AE-450B-8061-9B624CD4741B@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-mptcp-multiaddressed-03 Thread-Index: AcwrsLswL5gUcue4QtGsSMhHrb5uxwAULdrw References: <0A2BA2A4-A3AE-450B-8061-9B624CD4741B@gmail.com> From: "Ford, Alan" To: "Andrew McGregor" , "Yoshifumi Nishida" , "Philip Eardley" , "Costin Raiciu" , "Mark Handley" , "Olivier Bonaventure" , Subject: Re: [multipathtcp] Review of draft-ietf-mptcp-multiaddressed-03 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 08:50:15 -0000 Many thanks for this very valuable feedback. We'll apply these comments and expect version -04 to be out soon. Some stuff inline... > -----Original Message----- > From: Andrew McGregor [mailto:andrewmcgr@gmail.com] > Sent: 15 June 2011 23:58 > To: Yoshifumi Nishida; Philip Eardley; Ford, Alan; Costin Raiciu; Mark > Handley; Olivier Bonaventure; multipathtcp@ietf.org > Subject: Review of draft-ietf-mptcp-multiaddressed-03 >=20 > I finally got to do this review, what with earthquakes and > reorganisations it was rather a mission. >=20 > I think this document is in good shape, most of my comments are little > textual items rather than substantive issues needing clarifications. >=20 > Three substantive issues first: >=20 > Section 3.3.1, page 21: >=20 > Note that checksumming relies on the TCP subflow containing > contiguous data, and therefore a TCP subflow MUST NOT use the Urgent > Pointer to interrupt an existing mapping. Further note, however, > that if Urgent data is received on a subflow, it SHOULD be mapped to > the data sequence space and delivered to the application analogous > to > Urgent data in regular TCP. >=20 > Once you receive urgent data, the world is no longer safe for the > checksum... so something needs to be said about what happens next after > the urgent data is delivered. RST everything and require new joins? The rule there is that Urgent data MUST NOT interrupt an existing data sequence mapping. (However, if an urgent pointer aligns exactly with a data sequence mapping, that can be treated as a chunk of urgent data analogous to regular TCP). As long as that rule is adhered to, no checksums should break. And if a checksum does break, you go through the standard fallback procedure (which usually involves closing the subflow). So I don't think we need to do anything as drastic as RST everything. > Section 3.3.1, page 22: >=20 > Data sequence numbers are always 64-bit quantities, and MUST be > maintained as such in implementations. >=20 > At the end of this paragraph, perhaps add: An implementation MAY choose > to send 32 or 64 bit Data Sequence Numbers independently for each > packet. >=20 > This is implicitly allowed by Appendix A, but I think it should be > explicit in this section. This should also be implied by much of the text in that paragraph, but if you think it makes things clearer we can add that. > Section 3.4.1, page 33: >=20 > A host that receives an ADD_ADDR but finds a connection setup to > that > address is unsuccessful SHOULD NOT perform further connection > attempts to this address for this connection. A sender that wants > to > trigger a new incoming connection attempt on a previously advertised > address can therefore refresh ADD_ADDR information by sending the > option again. >=20 > This is inconsistent with section 3.7.3, page 39: >=20 > From the connection initiator's point of view, if an MP_JOIN > fails, it SHOULD NOT attempt to connect to the same IP address > during > the lifetime of the connection, unless the other host refreshes the > information with a REMOVE_ADDR and then an ADD_ADDR for the same > address. >=20 > Should this read: it SHOULD NOT attempt to connect to the same IP > address and port number Yes, it should, thanks. > An MP_JOIN may fail if the initiator is behind a NAT and is not aware > that it joined from the same IP address, so a join to the same remote > port number fails where a join to a different port would succeed. > Conversely, it may be desirable not to allow this situation to initiate > multiple subflows. >=20 > And in any case, these two paragraphs should be consistent with each > other as to how the address should be refreshed. Good point, I think we were converging on ADD_ADDR being a refresh with no need for a REMOVE_ADDR so we'll remove that mention to REMOVE_ADDR in 3.7.3. Many thanks again for spending the time looking at this, it's greatly appreciated. Cheers, Alan From andrewmcgr@gmail.com Thu Jun 16 02:13:03 2011 Return-Path: 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 792D111E81E9 for ; Thu, 16 Jun 2011 02:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xh8M+4Zl4OIN for ; Thu, 16 Jun 2011 02:13:03 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 00DC511E81DE for ; Thu, 16 Jun 2011 02:13:02 -0700 (PDT) Received: by pwi5 with SMTP id 5so575732pwi.31 for ; Thu, 16 Jun 2011 02:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=evfsROn2jhL9Vp3BX10zAwdETvzOGm5HoARp/Fhsugk=; b=NAFDSSC7E1ten5jGY/4xSDAIXUoEtKFbCjSoJZhJWtQM4CTAtygNo76HUZWmAU2N8a rpz79BjqFPzIJfVIMAGxxxxHftOZ0RXI2V9KpZWE0If8J2bc11SUHCbxIUiTJUpmXIYL UQd9O9ywHXUCkHUuzkBkQs0EjBu7Xyahvaa0Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=ctooCXQpE+mOh3evCo3cjufht7rI16grNmAFEGz2B9wi2jnyKYcwK7dv0+9nRlcl5p UDOimhFoYCAWNmFWjQoJ7eh2hYB829128+cc7E6I6f18rvng1SPjM59CipJowPS5ScM6 z8mMlI2mJyjxv7YKSZMd8kHHtKvpaNVE5+LFA= Received: by 10.142.237.21 with SMTP id k21mr101366wfh.174.1308215582596; Thu, 16 Jun 2011 02:13:02 -0700 (PDT) Received: from andrewm-lo.lan (121-72-129-86.dsl.telstraclear.net [121.72.129.86]) by mx.google.com with ESMTPS id d15sm1423595wfl.18.2011.06.16.02.12.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Jun 2011 02:13:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Andrew McGregor In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D680D0E23DB@rsys005a.comm.ad.roke.co.uk> Date: Thu, 16 Jun 2011 21:12:54 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0A2BA2A4-A3AE-450B-8061-9B624CD4741B@gmail.com> <2181C5F19DD0254692452BFF3EAF1D680D0E23DB@rsys005a.comm.ad.roke.co.uk> To: "Ford, Alan" X-Mailer: Apple Mail (2.1084) Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Review of draft-ietf-mptcp-multiaddressed-03 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 09:13:03 -0000 On 16/06/2011, at 8:50 PM, Ford, Alan wrote: > Many thanks for this very valuable feedback. We'll apply these = comments > and expect version -04 to be out soon. >=20 > Some stuff inline... >>=20 >> Once you receive urgent data, the world is no longer safe for the >> checksum... so something needs to be said about what happens next > after >> the urgent data is delivered. RST everything and require new joins? >=20 > The rule there is that Urgent data MUST NOT interrupt an existing data > sequence mapping. (However, if an urgent pointer aligns exactly with a > data sequence mapping, that can be treated as a chunk of urgent data > analogous to regular TCP). >=20 > As long as that rule is adhered to, no checksums should break. And if = a > checksum does break, you go through the standard fallback procedure > (which usually involves closing the subflow). >=20 > So I don't think we need to do anything as drastic as RST everything. Ah, right. I see how that works now. >=20 >> Section 3.3.1, page 22: >>=20 >> Data sequence numbers are always 64-bit quantities, and MUST be >> maintained as such in implementations. >>=20 >> At the end of this paragraph, perhaps add: An implementation MAY > choose >> to send 32 or 64 bit Data Sequence Numbers independently for each >> packet. >>=20 >> This is implicitly allowed by Appendix A, but I think it should be >> explicit in this section. >=20 > This should also be implied by much of the text in that paragraph, but > if you think it makes things clearer we can add that. I do, yes, I noted it on the first read as a bit confusing, and it was = only cleared up by reading the appendix. >=20 > Many thanks again for spending the time looking at this, it's greatly > appreciated. >=20 > Cheers, > Alan >=20 No problem, I wanted to do it... but like I said, events surrounding me = rather got in the way. Andrew= From internet-drafts@ietf.org Thu Jun 16 03:51:02 2011 Return-Path: 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 45F2021F84BC; Thu, 16 Jun 2011 03:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4XoIdOWVnNe; Thu, 16 Jun 2011 03:51:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEA121F84B9; Thu, 16 Jun 2011 03:51:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110616105100.4839.52144.idtracker@ietfa.amsl.com> Date: Thu, 16 Jun 2011 03:51:00 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-congestion-05.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 10:51:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multipath TCP Working Group of the IE= TF. Title : Coupled Congestion Control for Multipath Transport Proto= cols Author(s) : Costin Raiciu Mark Handley Damon Wischik Filename : draft-ietf-mptcp-congestion-05.txt Pages : 12 Date : 2011-06-16 Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP. New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, hence achieving resource pooling. This would increase the overall efficiency of the network and also its robustness to failure. This document presents a congestion control algorithm which couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-congestion-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-congestion-05.txt From georg.hampel@alcatel-lucent.com Thu Jun 16 08:03:12 2011 Return-Path: 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 D9ED29E801D for ; Thu, 16 Jun 2011 08:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4PD-gp1GiiI for ; Thu, 16 Jun 2011 08:03:10 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 73F8A9E8018 for ; Thu, 16 Jun 2011 08:03:10 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p5GF39f4004797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 16 Jun 2011 10:03:09 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5GF39QX002699 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 16 Jun 2011 10:03:09 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 16 Jun 2011 10:03:08 -0500 From: "Hampel, K Georg (K Georg)" To: "multipathtcp@ietf.org" Date: Thu, 16 Jun 2011 10:03:07 -0500 Thread-Topic: New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: AcwsNoAEwA+vzYT/SF6zM7ztidT2sg== Message-ID: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC443484D61294USNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "Klein, Thierry E \(Thierry\)" Subject: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 15:03:13 -0000 --_000_154773479ED2314980CB638A48FC443484D61294USNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, We have uploaded a new I-D. Title: Enhancements to Improve the Applicability of Multipath TCP to Wirele= ss Access Networks Authors: Georg Hampel, Thierry Klein Filename: draft-hampel-mptcp-applicability-wireless-networks-00.txt URL: http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-wirel= ess-networks/ Abstract: This document analyses the applicability of Multipath TCP to wireless acces= s networks with overlapping coverage area, and it discusses potential proto= col extensions that aim to improve operation in such environments. The ana= lysis attempts to identify use cases, benefits as well as technical and fun= ctional obstacles encountered in the current version of the protocol. Base= d on this analysis, recommendations are made on feature-, signaling- and po= licy extensions that promise to enhance Multipath-TCP's value, versatility = and market acceptance in wireless access networks. IMPORTANT COMMENTS: Apart from a variety of recommendations for research, t= he I-D proposes the following signaling and policy enhancements: MP_SELECT option: The host sends this option to enforce path-selective operation on its peer.= The option is generally sent on the subflow to be used for data transmiss= ion. It may enclose an address id in case it is sent on another subflow, e.= g. in break-before-make scenarios before the designated path becomes availa= ble. The option permits low-complexity MPTCP receiver solutions (Section 4.= 4) as well as dynamic overhead shedding for heavily loaded servers (Section= 4.5). AVAIL_ADDR/UNAVAIL_ADDR option(s): The host sends this option to inform its peer about the availability/unavai= lability status of an interface referred to via an address id. The enclose= d address-id permits sending the option from an available interface to refe= r to an unavailable interface. The option permits the peer to swiftly adjus= t data transmission when the host's interface availability changes. There a= re multiple use cases for this option (Section 3.6, Section 4.4 and Section= 4.5). DEFER_ADDR option: The host sends this option to instruct its peer to use a specific address r= eferred to via an address id as the destination for all future subflows. Th= is option is required for transparent-proxy operation (section 5). ADD_ADDR option: The present version of this option should be modified: The option should on= ly provide a mapping between address id and address value without further a= dvice or request for action. When the ADD_ADDRESS option refers to the sour= ce address of the packet it is enclosed in, it can omit the address value. = The re-interpretation of this option is necessary to support multiple instr= uctions as provided by the options above (and the one below). JOIN_ADDR option: The host sends this option to request subflow creation (via MP_JOIN) to an = address referred to via the enclosed address id. Currently, the functionali= ty of this option is melted into the ADD_ADDR option. DSS insertion policy for bulk transfer: To reduce receiver complexity, DSS options should be inserted into all pack= ets of a bulk until the first data ACK is received for a packet contained i= n the bulk (Section 3.7). Please take the details from the corresponding sections of the document. Co= mments are welcome. Thank you. Regards, Georg Hampel --_000_154773479ED2314980CB638A48FC443484D61294USNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 
We=
 have uploaded a new I-D.
 
Ti=
tle: Enhancements to Improve the Applicability of Multipath TCP to Wireless=
 Access Networks

 

Authors: Georg Hampel, Thierry= Klein

 

Filename: draft-hampel-mptcp-applicability-wireless-networks-00.tx=
t

 

URL: http://datatracker.ietf.org/doc/draft-hampel-mptcp-applic= ability-wireless-networks/

 

Abstract:

This document analyses the applicability of Multipath TC= P to wireless access networks with overlapping coverage area, and it discusses potential protocol extensions that aim to improve operation in such environments.  The analysis attempts to identify use cases, benefits a= s well as technical and functional obstacles encountered in the current versi= on of the protocol.  Based on this analysis, recommendations are made on feature-, signaling- and policy extensions that promise to enhance Multipath-TCP's value, versatility and market acceptance in wireless access networks.

 

 

IMPORTANT COMMENTS: Apart from a variety of recommendati= ons for research, the I-D proposes the following signaling and policy enhancements:=

 

MP_SELECT option:

The host sends this option to enforce path-selective operation on its peer.  The option is generally sent on the subflow to= be used for data transmission. It may enclose an address id in case it is sent= on another subflow, e.g. in break-before-make scenarios before the designated = path becomes available. The option permits low-complexity MPTCP receiver solutio= ns (Section 4.4) as well as dynamic overhead shedding for heavily loaded serve= rs (Section 4.5).

 

AVAIL_ADDR/UNAVAIL_ADDR option(s):

The host sends this option to inform its peer about the availability/unavailability status of an interface referred to via an addre= ss id.  The enclosed address-id permits sending the option from an availa= ble interface to refer to an unavailable interface. The option permits the peer= to swiftly adjust data transmission when the host’s interface availability chang= es. There are multiple use cases for this option (Section 3.6, Section 4.4 and Section 4.5).

 

DEFER_ADDR option:

The host sends this option to instruct its peer to use a specific address referred to via an address id as the destination for all future subflows. This option is required for transparent-proxy operation (section 5).

 

ADD_ADDR option:

The present version of this option should be modified: T= he option should only provide a mapping between address id and address value w= ithout further advice or request for action. When the ADD_ADDRESS option refers to= the source address of the packet it is enclosed in, it can omit the address val= ue. The re-interpretation of this option is necessary to support multiple instructions as provided by the options above (and the one below).

 

JOIN_ADDR option:

The host sends this option to request subflow creation (= via MP_JOIN) to an address referred to via the enclosed address id. Currently, = the functionality of this option is melted into the ADD_ADDR option.=

 

DSS insertion policy for bulk transfer:

To reduce receiver complexity, DSS options should be inserted into all packets of a bulk until the first data ACK is received fo= r a packet contained in the bulk (Section 3.7).

 

 

Please take the details from t= he corresponding sections of the document. Comments are welcome. Thank you.

 

Regards,

Georg Hampel=

 

 

 

--_000_154773479ED2314980CB638A48FC443484D61294USNAVSXCHMBSA2n_-- From prvs=0153e612c9=alan.ford@roke.co.uk Tue Jun 21 02:49:56 2011 Return-Path: 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 114859E8046 for ; Tue, 21 Jun 2011 02:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ouu9IveYaVzE for ; Tue, 21 Jun 2011 02:49:52 -0700 (PDT) Received: from gse-mta-29.emailfiltering.com (gse-mta-29-tx.emailfiltering.com [194.116.198.160]) by ietfa.amsl.com (Postfix) with ESMTP id 4F59A9E8049 for ; Tue, 21 Jun 2011 02:49:51 -0700 (PDT) Received: from salt-ext.roke.co.uk ([109.207.29.2]) by gse-mta-29.emailfiltering.com with emfmta (version 4.8.2.32) vanilla id 441305420 for multipathtcp@ietf.org; 644923459b511afa; Tue, 21 Jun 2011 10:49:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC2FF8.87E2CCF8" Date: Tue, 21 Jun 2011 10:49:35 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680D15D18D@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: AcwsNoAEwA+vzYT/SF6zM7ztidT2sgDuBMNg References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> From: "Ford, Alan" To: "Hampel, K Georg \(K Georg\)" , Cc: "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 09:49:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2FF8.87E2CCF8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Georg, Thierry, =20 Thanks for writing this - it covers an important and interesting topic. I've had a chance to read it, now, and have some comments. =20 3.3: It is definitely intentional that you can use MPTCP with no changes to send data resiliently on many paths. I'll expand the text in the protocol draft slightly to discuss processing the same mappings on different subflows. =20 3.4: Agreed, this (fluctuations in path throughput/delay) is a very valid concern and one that we discuss considerably in the API draft. It is an issue where users are best placed to drive the development of solutions. =20 3.7: This idea is sensible, but I would be reluctant to mandate it. I think some text like this may be sufficient: "An implementation SHOULD send DSS options that cover multiple segments multiple times, to reduce the need for unnecessary buffering at the receiver. It is RECOMMENDED that a sender repeats the DSS option until a DATA ACK for some data covered by this mapping is received." =20 "Path Availability" - this is where I get confused as to what the goal of this is. Can you give an example scenario where this would be useful? Throughout the rest of this document, I struggle to see what difference there is between path (or interface) availability, and address availability. We have the ADD_ADDR and REMOVE_ADDR options to indicate the availability or loss of availability of an address (interface) on a host. What is (UN)AVAIL_ADDR giving over and above this? Why separate the creation of the mapping and the signalling of the availability? =20 Some points on 4.4: =20 Yes, MP_PRIO is not binding, although the expectation is that a host should have a good reason for ignoring it (such as if the path appears dead to the host, or it costs too much money) - I can't see that we can change that. If an end host was desperate to stop receiving traffic on an interface, it could drop the subflow. =20 If I understand your comment correctly, you'd like to be able to switch a single path to B=3D0 and all the others to B=3D1 in one go, and this = is the purpose of MP_SELECT? I guess we could adapt MP_PRIO to achieve this, by having another value that means "use me and me alone". Although I think I need more convincing that it adds value! =20 In 4.4.2, you talk about BBM in the scenario of a radio knowing that it is going to take down its interface to attach to a new network. You can do this already cleanly - just FIN the old path (without a DATA FIN) and bring up the new one. What is your proposal adding? =20 5.1 is an interesting problem and one that Mark led some discussion of at the last IETF. As with the discussion about AVAIL_ADDR, I don't see the point of JOIN_ADDR and ADD_ADDR separations, but DEFER_ADDR (or "USE_THIS_ADDR!") is an interesting idea that I need to think about some more! =20 Regards, Alan =20 From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Hampel, K Georg (K Georg) Sent: 16 June 2011 16:03 To: multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks =20 All, =20 We have uploaded a new I-D. =20 Title: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks =20 Authors: Georg Hampel, Thierry Klein =20 Filename: draft-hampel-mptcp-applicability-wireless-networks-00.txt =20 URL: http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-wireles s-networks/ =20 Abstract: This document analyses the applicability of Multipath TCP to wireless access networks with overlapping coverage area, and it discusses potential protocol extensions that aim to improve operation in such environments. The analysis attempts to identify use cases, benefits as well as technical and functional obstacles encountered in the current version of the protocol. Based on this analysis, recommendations are made on feature-, signaling- and policy extensions that promise to enhance Multipath-TCP's value, versatility and market acceptance in wireless access networks. =20 =20 IMPORTANT COMMENTS: Apart from a variety of recommendations for research, the I-D proposes the following signaling and policy enhancements:=20 =20 MP_SELECT option: The host sends this option to enforce path-selective operation on its peer. The option is generally sent on the subflow to be used for data transmission. It may enclose an address id in case it is sent on another subflow, e.g. in break-before-make scenarios before the designated path becomes available. The option permits low-complexity MPTCP receiver solutions (Section 4.4) as well as dynamic overhead shedding for heavily loaded servers (Section 4.5). =20 AVAIL_ADDR/UNAVAIL_ADDR option(s): The host sends this option to inform its peer about the availability/unavailability status of an interface referred to via an address id. The enclosed address-id permits sending the option from an available interface to refer to an unavailable interface. The option permits the peer to swiftly adjust data transmission when the host's interface availability changes. There are multiple use cases for this option (Section 3.6, Section 4.4 and Section 4.5). =20 DEFER_ADDR option:=20 The host sends this option to instruct its peer to use a specific address referred to via an address id as the destination for all future subflows. This option is required for transparent-proxy operation (section 5). =20 ADD_ADDR option: The present version of this option should be modified: The option should only provide a mapping between address id and address value without further advice or request for action. When the ADD_ADDRESS option refers to the source address of the packet it is enclosed in, it can omit the address value. The re-interpretation of this option is necessary to support multiple instructions as provided by the options above (and the one below). =20 JOIN_ADDR option:=20 The host sends this option to request subflow creation (via MP_JOIN) to an address referred to via the enclosed address id. Currently, the functionality of this option is melted into the ADD_ADDR option. =20 DSS insertion policy for bulk transfer:=20 To reduce receiver complexity, DSS options should be inserted into all packets of a bulk until the first data ACK is received for a packet contained in the bulk (Section 3.7). =20 =20 Please take the details from the corresponding sections of the document. Comments are welcome. Thank you. =20 Regards, Georg Hampel =20 =20 =20 ------_=_NextPart_001_01CC2FF8.87E2CCF8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Georg, Thierry,

 

Thanks for writing this – it covers an important and interesting topic. = I’ve had a chance to read it, now, and have some = comments.

 

3.3: It is definitely intentional that you can use MPTCP with no changes to = send data resiliently on many paths. I’ll expand the text in the = protocol draft slightly to discuss processing the same mappings on different = subflows.

 

3.4: Agreed, this (fluctuations in path throughput/delay) is a very valid = concern and one that we discuss considerably in the API draft.  It is an = issue where users are best placed to drive the development of = solutions.

 

3.7: This idea is sensible, but I would be reluctant to mandate it.  I = think some text like this may be sufficient: “An implementation SHOULD = send DSS options that cover multiple segments multiple times, to reduce the need = for unnecessary buffering at the receiver.  It is RECOMMENDED that a = sender repeats the DSS option until a DATA ACK for some data covered by this = mapping is received.”

 

“Path Availability” – this is where I get confused as to what the = goal of this is. Can you give an example scenario where this would be = useful?

Throughout the rest of this document, I struggle to see what difference there is = between path (or interface) availability, and address availability.  We have the ADD_ADDR and REMOVE_ADDR options to indicate the availability or loss of availability of an address (interface) on a host.  What is = (UN)AVAIL_ADDR giving over and above this? Why separate the creation of the mapping and = the signalling of the availability?

 

Some points on 4.4:

 

Yes, MP_PRIO is not binding, although the expectation is that a host should = have a good reason for ignoring it (such as if the path appears dead to the = host, or it costs too much money) – I can’t see that we can change = that.  If an end host was desperate to stop receiving traffic on an interface, it = could drop the subflow.

 

If I understand your comment correctly, you’d like to be able to = switch a single path to B=3D0 and all the others to B=3D1 in one go, and this is = the purpose of MP_SELECT?  I guess we could adapt MP_PRIO to achieve this, by = having another value that means “use me and me alone”.  = Although I think I need more convincing that it adds value!

 

In 4.4.2, you talk about BBM in the scenario of a radio knowing that = it is going to take down its interface to attach to a new network.  You = can do this already cleanly – just FIN the old path (without a DATA FIN) = and bring up the new one.  What is your proposal = adding?

 

5.1 is an interesting problem and one that Mark led some discussion of at = the last IETF.  As with the discussion about AVAIL_ADDR, I don’t see = the point of JOIN_ADDR and ADD_ADDR separations, but DEFER_ADDR (or = “USE_THIS_ADDR!”) is an interesting idea that I need to think about some = more!

 

Regards,<= /o:p>

Alan

 

From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Hampel, K = Georg (K Georg)
Sent: 16 June 2011 16:03
To: multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierry)
Subject: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access = Networks

 

All,

 
= 
We have uploaded =
a new I-D.
 
= 
Title: =
Enhancements to Improve the Applicability of Multipath TCP to Wireless =
Access Networks

 

Authors: = Georg Hampel, Thierry Klein

 

Filename: =
draft-hampel-mptcp-applicability-wireless-networks-00.txt

 

URL: http://datatracker.ietf.org/doc/draft-hampel-mptcp-ap= plicability-wireless-networks/

 

Abstract:

This document analyses the applicability of Multipath TCP to wireless access networks with overlapping coverage area, and it discusses potential = protocol extensions that aim to improve operation in such environments.  The analysis attempts to identify use cases, benefits as well as technical = and functional obstacles encountered in the current version of the = protocol.  Based on this analysis, recommendations are made on feature-, signaling- = and policy extensions that promise to enhance Multipath-TCP's value, = versatility and market acceptance in wireless access networks.

 

 

IMPORTANT COMMENTS: Apart from a variety of recommendations for research, the I-D proposes the following signaling and policy enhancements: =

 

MP_SELECT option:

The host sends this option to enforce path-selective operation on its = peer.  The option is generally sent on the subflow to be used for data = transmission. It may enclose an address id in case it is sent on another subflow, e.g. = in break-before-make scenarios before the designated path becomes = available. The option permits low-complexity MPTCP receiver solutions (Section 4.4) as = well as dynamic overhead shedding for heavily loaded servers (Section = 4.5).

 

AVAIL_ADDR/UNAVAIL_ADDR option(s):

The host sends this option to inform its peer about the = availability/unavailability status of an interface referred to via an address id.  The enclosed address-id permits sending the option from an available interface to = refer to an unavailable interface. The option permits the peer to swiftly adjust = data transmission when the host’s interface availability changes. There = are multiple use cases for this option (Section 3.6, Section 4.4 and Section = 4.5).

 

DEFER_ADDR option:

The host sends this option to instruct its peer to use a specific address = referred to via an address id as the destination for all future subflows. This = option is required for transparent-proxy operation (section = 5).

 

ADD_ADDR option:

The present version of this option should be modified: The option should = only provide a mapping between address id and address value without further = advice or request for action. When the ADD_ADDRESS option refers to the source = address of the packet it is enclosed in, it can omit the address value. The re-interpretation of this option is necessary to support multiple = instructions as provided by the options above (and the one = below).

 

JOIN_ADDR option:

The host sends this option to request subflow creation (via MP_JOIN) to an = address referred to via the enclosed address id. Currently, the functionality of = this option is melted into the ADD_ADDR option.

 

DSS insertion policy for bulk transfer:

To reduce receiver complexity, DSS options should be inserted into all = packets of a bulk until the first data ACK is received for a packet contained in = the bulk (Section 3.7).

 

 

Please take = the details from the corresponding sections of the document. Comments are = welcome. Thank you.

 

Regards,=

Georg = Hampel

 

 

 

------_=_NextPart_001_01CC2FF8.87E2CCF8-- From christoph.paasch@uclouvain.be Tue Jun 21 04:14:12 2011 Return-Path: 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 B279F11E8079 for ; Tue, 21 Jun 2011 04:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEL5E0UGlNEr for ; Tue, 21 Jun 2011 04:14:11 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5920D11E8073 for ; Tue, 21 Jun 2011 04:14:10 -0700 (PDT) Received: from cpaasch-mac.localnet (unknown [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id ECB6B11E242; Tue, 21 Jun 2011 13:14:04 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be ECB6B11E242 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1308654844; bh=DYBDjqv95V2/9J96EmtsPUCG6ahAV5PWdc+QLMs8raM=; h=From:Reply-To:To:Subject:Date:Cc:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id; b=NchNaySxpota+dWw2iCeEHzx1Mg8EyQUFtvfUUptwxRTfEKpB3f+YmD/x85WE8FVm j32TBieYSddMxf/YVaziLoSDOw2FZwjJCa3s8XxIubZqsoNvRgkJP1UxKssGFqiUTT xJkoFjqw336C/encNNFBHjAF/ixIod7ys8H/xHYU= From: Christoph Paasch Organization: =?iso-8859-1?q?Universit=E9_Catholique_de?= Louvain To: multipathtcp@ietf.org Date: Tue, 21 Jun 2011 13:14:04 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic; KDE/4.6.2; x86_64; ; ) References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D15D18D@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D680D15D18D@rsys005a.comm.ad.roke.co.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201106211314.04612.christoph.paasch@uclouvain.be> X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: ECB6B11E242.A32CC X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] =?iso-8859-15?q?New_I-D=3A_Enhancements_to_Improve?= =?iso-8859-15?q?_the=09Applicability_of_Multipath_TCP_to_Wireless_Access_?= =?iso-8859-15?q?Networks?= X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 11:14:12 -0000 Hi all, I took also some time to read the draft and have some comments on your draf= t=20 and on Alan's comments. 3.6: "The ADD_ADDR option can be simplified when it refers to the packet's sourc= e=20 address." I don't see a case where the ADD_ADDR-option is sent, refering to the packe= t's=20 source address, because the address-id of this source-address has already b= een=20 provided by the MP_JOIN when establishing the subflow. On Tuesday 21 June 2011 wrote Ford, Alan: > 3.7: This idea is sensible, but I would be reluctant to mandate it. I > think some text like this may be sufficient: "An implementation SHOULD > send DSS options that cover multiple segments multiple times, to reduce > the need for unnecessary buffering at the receiver. It is RECOMMENDED > that a sender repeats the DSS option until a DATA ACK for some data > covered by this mapping is received." In fact, if the first packet (carrying the DSS) is lost, packets will be=20 stored in the subflow-specific out-of-order queue, because we have a loss a= t=20 the subflow-level. In any case, as long as the whole mapping of the payload has not been=20 received, we need to buffer the packets for the checksum-verification. 4.3: "In case the old subflow becomes unavailable, retransmissions can..." Maybe you should note, that the retransmissions have to be done on the new= =20 subflow before the regular data-stream. Otherwise you might have problems, = in=20 the next paragraph. Concerning your removal of the DSS-options. Is it intended that after remov= ing=20 the DSS-options the host is still able to switch to another subflow? If this is the case, then we have problems with middleboxes modifying the=20 content of packets (e.g., IP-address rewriting). If they add/remove a byte,= =20 the data-sequence mapping between the two hosts isn't the same anymore. 4.3: "Using only one flow/congestion engine significantly..." So, the intention is to have the same congestion-window and slow-start- threshhold on the new subflow as on the old-one, and thus you do not slow- start on the new subflow? I'm not sure if this is a good idea. You will probably overload the network= in=20 the beginning. It may also be, that statefull firewalls are dropping packet= s,=20 because they do not fit in the expected window. > "Path Availability" - this is where I get confused as to what the goal > of this is. Can you give an example scenario where this would be useful? >=20 > Throughout the rest of this document, I struggle to see what difference > there is between path (or interface) availability, and address > availability. We have the ADD_ADDR and REMOVE_ADDR options to indicate > the availability or loss of availability of an address (interface) on a > host. What is (UN)AVAIL_ADDR giving over and above this? Why separate > the creation of the mapping and the signalling of the availability? Agree with Alan on this point. I don't really see the difference between=20 ADD/REMOVE and AVAIL/UNAVAIL. 4.4.2: "Obviously, the host most have announced the mapping between address id and= =20 address value prior to the handover using the ADD_ADDRESS option." Here, we are in the BBM-scenario. Thus, we do not yet have the new address.= So=20 we cannot announce it with ADD_ADDR, because we don't know which address we= =20 will get. Cheers, Christoph =2D- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp Universit=E9 Catholique de Louvain www.rollerbulls.be =2D- From iesg-secretary@ietf.org Tue Jun 21 06:31:51 2011 Return-Path: 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 70A7511E80F9; Tue, 21 Jun 2011 06:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8mrWbhBZ6xz; Tue, 21 Jun 2011 06:31:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7C911E8083; Tue, 21 Jun 2011 06:31:50 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110621133150.30079.61276.idtracker@ietfa.amsl.com> Date: Tue, 21 Jun 2011 06:31:50 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] Last Call: (Coupled Congestion Control for Multipath Transport Protocols) to Experimental RFC X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 13:31:51 -0000 The IESG has received a request from the Multipath TCP WG (mptcp) to consider the following document: - 'Coupled Congestion Control for Multipath Transport Protocols' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP. New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, hence achieving resource pooling. This would increase the overall efficiency of the network and also its robustness to failure. This document presents a congestion control algorithm which couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mptcp-congestion/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mptcp-congestion/ No IPR declarations have been submitted directly on this I-D. From georg.hampel@alcatel-lucent.com Tue Jun 21 08:44:59 2011 Return-Path: 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 57B5411E827F for ; Tue, 21 Jun 2011 08:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBaDOg+Qg60J for ; Tue, 21 Jun 2011 08:44:53 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0708811E80AE for ; Tue, 21 Jun 2011 08:44:52 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p5LFipel017196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 21 Jun 2011 10:44:51 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5LFhrtK013098 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Jun 2011 10:43:54 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 21 Jun 2011 10:43:53 -0500 From: "Hampel, K Georg (K Georg)" To: "Ford, Alan" , "multipathtcp@ietf.org" Date: Tue, 21 Jun 2011 10:43:51 -0500 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: AcwsNoAEwA+vzYT/SF6zM7ztidT2sgDuBMNgAAwbvkA= Message-ID: <154773479ED2314980CB638A48FC443484DC89D5@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D15D18D@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D680D15D18D@rsys005a.comm.ad.roke.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC443484DC89D5USNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:44:59 -0000 --_000_154773479ED2314980CB638A48FC443484DC89D5USNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Alan, Thanks for reading the draft. We are currently implementing a low-complexi= ty MPTCP version for path-selective mode (see section 4 of draft). Many of = the issues in section 4 came up when we thought through the specific steps = for such a design. There are multiple ways to tackle these issues. I have a= dded comments below. Regards, Georg ________________________________ From: Ford, Alan [mailto:alan.ford@roke.co.uk] Sent: Tuesday, June 21, 2011 5:50 AM To: Hampel, K Georg (K Georg); multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hello Georg, Thierry, Thanks for writing this - it covers an important and interesting topic. I'v= e had a chance to read it, now, and have some comments. 3.3: It is definitely intentional that you can use MPTCP with no changes to= send data resiliently on many paths. I'll expand the text in the protocol = draft slightly to discuss processing the same mappings on different subflow= s. 3.4: Agreed, this (fluctuations in path throughput/delay) is a very valid c= oncern and one that we discuss considerably in the API draft. It is an iss= ue where users are best placed to drive the development of solutions. 3.7: This idea is sensible, but I would be reluctant to mandate it. I thin= k some text like this may be sufficient: "An implementation SHOULD send DSS= options that cover multiple segments multiple times, to reduce the need fo= r unnecessary buffering at the receiver. It is RECOMMENDED that a sender r= epeats the DSS option until a DATA ACK for some data covered by this mappin= g is received." "Path Availability" - this is where I get confused as to what the goal of t= his is. Can you give an example scenario where this would be useful? Throughout the rest of this document, I struggle to see what difference the= re is between path (or interface) availability, and address availability. = We have the ADD_ADDR and REMOVE_ADDR options to indicate the availability o= r loss of availability of an address (interface) on a host. What is (UN)AV= AIL_ADDR giving over and above this? Why separate the creation of the mappi= ng and the signalling of the availability? [G.H.] The "Path availability" option shows up in sections 3.6 and 4.4.2. H= ere is an example that applies to section 3.6: A multi-homed mobile downloads a data stream from a server using 2 interfac= es, say, Wifi & 4G. Suddenly, a lower-layer signal on the mobile indicates= that the 4G interface has dropped off (coverage hole or fade). The server = does not know about this signal and keeps pumping data along both paths. Th= e data sent to the Wifi interface arrive but they cannot get delivered sinc= e all 4G-data get dropped. When RTO is exceeded for the 4G path, the server= starts to realize that something is wrong and engages into retransmission,= most likely on the same subflow first and after even more time, it engages= into cross-subflow retransmission (dependent on local policy). The whole mess could get resolved much faster if the mobile quickly informe= d the server about the sudden unavailability of its 4G interface. In this c= ase, the server would be certain within 1/2 RTT that the "4G" interface is = currently NOT good and it can immediately redirect all data including 4G-re= transmissions to the "WiFi" path. The mobile should NOT tear down the "4G" = path since it can be back up any moment. Further, MP_PRIO cannot be used si= nce it cannot be sent on an unavailable path. Moreover, the MP_PRIO refers = to individual paths, while the present problem applies to a specific interf= ace, i.e. which may affect multiple paths. Some points on 4.4: Yes, MP_PRIO is not binding, although the expectation is that a host should= have a good reason for ignoring it (such as if the path appears dead to th= e host, or it costs too much money) - I can't see that we can change that. = If an end host was desperate to stop receiving traffic on an interface, it= could drop the subflow. If I understand your comment correctly, you'd like to be able to switch a s= ingle path to B=3D0 and all the others to B=3D1 in one go, and this is the = purpose of MP_SELECT? I guess we could adapt MP_PRIO to achieve this, by h= aving another value that means "use me and me alone". Although I think I n= eed more convincing that it adds value! [G.H] I think you summarized the essence of MP_SELECT rather well. There ar= e multiple ways of doing this. The goal of all this is that the host can EN= FORCE path-selective operation on the peer's sender since this simplifies t= he host's receiver, AND that path-reselection can be done in the FASTEST an= d MOST RELIABLE possible way. Constraints are: (1) MP_PRIO with B=3D1 canno= t be sent on a path that is already down, (2) uncertainty when multiple MP_= PRIO message with different B-setting arrive out of sync due to the differe= nt RTTs on the various paths, (3) conflict resolution, i.e. host A wants re= ceive data on path 1 but host B wants to send data on path 2, (4) long dela= y in case "switching messages" get lost. In 4.4.2, you talk about BBM in the scenario of a radio knowing that it is = going to take down its interface to attach to a new network. You can do th= is already cleanly - just FIN the old path (without a DATA FIN) and bring u= p the new one. What is your proposal adding? [G.H.] We had an MPTCP mailing list discussion on BBM. From this discussion= I understand that BBM on lower layer should NOT be followed on L4. The rea= sons given were: When a host with one radio interface rapidly ping-pongs be= tween two networks (lower-layer BBM at every switch), MPTCP should keep bot= h subflows up and solely change the activity of each path. In other words, = BBM on lower layers is translated to MBB on MPTCP. Your proposal, i.e. send= ing FIN on the old path, would make a switchback to the old path very slow = (since you have to MP_JOIN again). Further, the remote peer may not respond= to FIN if it still has data to send (!). The BBM ping-pong scenario is ano= ther reason for AVAIL/UNAVAIL_ADDR. 5.1 is an interesting problem and one that Mark led some discussion of at t= he last IETF. As with the discussion about AVAIL_ADDR, I don't see the poi= nt of JOIN_ADDR and ADD_ADDR separations, but DEFER_ADDR (or "USE_THIS_ADDR= !") is an interesting idea that I need to think about some more! [G.H.] I think Mark had a more generic proxy solution in mind. The "transpa= rent" proxy we are proposing has much more stringent deployment requirement= s. However, there is a very important use case (put it on PDN-GW) and it ca= n be realized through a very simple signalling enhancement ("USE_THIS_ADDR"= may indeed be clearer). Regards, Alan From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Hampel, K Georg (K Georg) Sent: 16 June 2011 16:03 To: multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: [multipathtcp] New I-D: Enhancements to Improve the Applicability = of Multipath TCP to Wireless Access Networks All, We have uploaded a new I-D. Title: Enhancements to Improve the Applicability of Multipath TCP to Wirele= ss Access Networks Authors: Georg Hampel, Thierry Klein Filename: draft-hampel-mptcp-applicability-wireless-networks-00.txt URL: http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-wirel= ess-networks/ Abstract: This document analyses the applicability of Multipath TCP to wireless acces= s networks with overlapping coverage area, and it discusses potential proto= col extensions that aim to improve operation in such environments. The ana= lysis attempts to identify use cases, benefits as well as technical and fun= ctional obstacles encountered in the current version of the protocol. Base= d on this analysis, recommendations are made on feature-, signaling- and po= licy extensions that promise to enhance Multipath-TCP's value, versatility = and market acceptance in wireless access networks. IMPORTANT COMMENTS: Apart from a variety of recommendations for research, t= he I-D proposes the following signaling and policy enhancements: MP_SELECT option: The host sends this option to enforce path-selective operation on its peer.= The option is generally sent on the subflow to be used for data transmiss= ion. It may enclose an address id in case it is sent on another subflow, e.= g. in break-before-make scenarios before the designated path becomes availa= ble. The option permits low-complexity MPTCP receiver solutions (Section 4.= 4) as well as dynamic overhead shedding for heavily loaded servers (Section= 4.5). AVAIL_ADDR/UNAVAIL_ADDR option(s): The host sends this option to inform its peer about the availability/unavai= lability status of an interface referred to via an address id. The enclose= d address-id permits sending the option from an available interface to refe= r to an unavailable interface. The option permits the peer to swiftly adjus= t data transmission when the host's interface availability changes. There a= re multiple use cases for this option (Section 3.6, Section 4.4 and Section= 4.5). DEFER_ADDR option: The host sends this option to instruct its peer to use a specific address r= eferred to via an address id as the destination for all future subflows. Th= is option is required for transparent-proxy operation (section 5). ADD_ADDR option: The present version of this option should be modified: The option should on= ly provide a mapping between address id and address value without further a= dvice or request for action. When the ADD_ADDRESS option refers to the sour= ce address of the packet it is enclosed in, it can omit the address value. = The re-interpretation of this option is necessary to support multiple instr= uctions as provided by the options above (and the one below). JOIN_ADDR option: The host sends this option to request subflow creation (via MP_JOIN) to an = address referred to via the enclosed address id. Currently, the functionali= ty of this option is melted into the ADD_ADDR option. DSS insertion policy for bulk transfer: To reduce receiver complexity, DSS options should be inserted into all pack= ets of a bulk until the first data ACK is received for a packet contained i= n the bulk (Section 3.7). Please take the details from the corresponding sections of the document. Co= mments are welcome. Thank you. Regards, Georg Hampel --_000_154773479ED2314980CB638A48FC443484DC89D5USNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Alan,

 

Thanks for reading the draft.  We= are currently implementing a low-complexity MPTCP version for path-selective mo= de (see section 4 of draft). Many of the issues in section 4 came up when we though= t through the specific steps for such a design. There are multiple ways to ta= ckle these issues. I have added comments below.

 

Regards,

Georg

 

From: Ford, Al= an [mailto:alan.ford@roke.co.uk]
Sent: Tuesday, June 21, 2011= 5:50 AM
To: Hampel, K Georg (K Georg= ); multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierr= y)
Subject: RE: [multipathtcp] = New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks=

 

Hello Georg, Thierry,

 

Thanks for wri= ting this – it covers an important and interesting topic. I’ve had a chance to read it, now, and have some comments.

 

3.3: It is definitely intentional that you can use MPTCP with no changes to send data resiliently on many paths. I’ll expand the text in the protocol draft slightly to discuss processing the same mappings on different subflows.

 

3.4: Agreed, t= his (fluctuations in path throughput/delay) is a very valid concern and one tha= t we discuss considerably in the API draft.  It is an issue where users are best placed to drive the development of solutions.=

 

3.7: This idea= is sensible, but I would be reluctant to mandate it.  I think some text l= ike this may be sufficient: “An implementation SHOULD send DSS options th= at cover multiple segments multiple times, to reduce the need for unnecessary buffering at the receiver.  It is RECOMMENDED that a sender repeats th= e DSS option until a DATA ACK for some data covered by this mapping is receiv= ed.”

 

“Path Av= ailability” – this is where I get confused as to what the goal of this is. Can yo= u give an example scenario where this would be useful?

Throughout the= rest of this document, I struggle to see what difference there is between path (= or interface) availability, and address availability.  We have the ADD_AD= DR and REMOVE_ADDR options to indicate the availability or loss of availabilit= y of an address (interface) on a host.  What is (UN)AVAIL_ADDR giving over = and above this? Why separate the creation of the mapping and the signalling of = the availability?

 

[G.H.] The “P= ath availability” option shows up in sections 3.6 and 4.4.2. Here is an example that applies to section 3.6:

 

A multi-homed mobil= e downloads a data stream from a server using 2 interfaces, say,  Wifi &= amp; 4G. Suddenly, a lower-layer signal on the mobile indicates that the 4G interface has dropped off (coverage hole or fade). The server does not know about this signal and keeps pumping data along both paths. The data sent to= the Wifi interface arrive but they cannot get delivered since all 4G-data get dropped. When RTO is exceeded for the 4G path, the server starts to realize that something is wrong and engages into retransmission, most likely on the same subflow first and after even more time, it engages into cross-subflow retransmission (dependent on local policy).

The whole mess coul= d get resolved much faster if the mobile quickly informed the server about the sudden unav= ailability of its 4G interface. In this case, the server would be certain within 1/2 R= TT that the “4G” interface is currently NOT good and it can immediately redirect all data including 4G-retransmissions to the “WiFi” pa= th. The mobile should NOT tear down the “4G” path since it can be b= ack up any moment. Further, MP_PRIO cannot be used since it cannot be sent on a= n unavailable path. Moreover, the MP_PRIO refers to individual paths, while t= he present problem applies to a specific interface, i.e. which may affect mult= iple paths.

 

Some points on= 4.4:

 

Yes, MP_PRIO i= s not binding, although the expectation is that a host should have a good reason = for ignoring it (such as if the path appears dead to the host, or it costs too = much money) – I can’t see that we can change that.  If an end h= ost was desperate to stop receiving traffic on an interface, it could drop the subflow.

 

If I understan= d your comment correctly, you’d like to be able to switch a single path to B= =3D0 and all the others to B=3D1 in one go, and this is the purpose of MP_SELECT?  I guess we could adapt MP_PRIO to achieve this, by having another value that means “use me and me alone”.  Although = I think I need more convincing that it adds value!

 

[G.H] I think you summarized the essence of MP_SELECT rather well. There are multiple ways of doing this. The goal of all this is that the host can ENFORCE path-selectiv= e operation on the peer’s sender since this simplifies the host’s receiver, AND that path-reselection can be done in the FASTEST and MOST RELIABLE possible way. Constraints are: (1) MP_PRIO with B=3D1 cannot be se= nt on a path that is already down, (2) uncertainty when multiple MP_PRIO message = with different B-setting arrive out of sync due to the different RTTs on the var= ious paths, (3) conflict resolution, i.e. host A wants receive data on path 1 bu= t host B wants to send data on path 2, (4) long delay in case “switchin= g messages” get lost.

 

In 4.4.2, you = talk about BBM in the scenario of a radio k= nowing that it is going to take down its interface to attach to a new network.&nbs= p; You can do this already cleanly – just FIN the old path (without a DA= TA FIN) and bring up the new one.  What is your proposal adding?

 =

[G.H.] We had an MP= TCP mailing list discussion on BBM. From this discussion I understand that BBM = on lower layer should NOT be followed on L4. The reasons given were: When a ho= st with one radio interface rapidly ping-pongs between two networks (lower-layer BB= M at every switch), MPTCP should keep both subflows up and solely change the activity of each path. In other words, BBM on lower layers is translated to= MBB on MPTCP. Your proposal, i.e. sending FIN on the old path, would make a swi= tchback to the old path very slow (since you have to MP_JOIN again). Further, the remote peer may not respond to FIN if it still has data to send (!). The BB= M ping-pong scenario is another reason for AVAIL/UNAVAIL_ADDR.

 

 

5.1 is an interesting problem and one that Mark led some discussion of at the last IETF.  As with the discussion about AVAIL_ADDR, I don’t see the point of JOIN_ADDR and ADD_ADDR separations, but DEFER_ADDR (or “USE_THIS_ADDR!”) is an interesting idea that I need to think a= bout some more!

 

[G.H.] I think Mark= had a more generic proxy solution in mind. The “transparent” proxy we= are proposing has much more stringent deployment requirements. However, there i= s a very important use case (put it on PDN-GW) and it can be realized through a very simple signalling enhancement (“USE_THIS_ADDR” may indeed = be clearer).

 

Regards,<= /o:p>

Alan

 

From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Hampel, K Georg (K Georg= )
Sent: 16 June 2011 16:03
To: multipathtcp@ietf.org Cc: Klein, Thierry E (Thierr= y)
Subject: [multipathtcp] New = I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Acce= ss Networks

 

All,

 
We=
 have uploaded a new I-D.
 
Ti=
tle: Enhancements to Improve the Applicability of Multipath TCP to Wireless=
 Access Networks

 

Authors: Georg Hampel, Thierry= Klein

 

Filename: draft-hampel-mptcp-applicability-wireless-networks-00.tx=
t

 

URL: http://datatracker.ietf.org/doc/draft-hampel-mptcp-applic= ability-wireless-networks/

 

Abstract:

This document analyses the applicability of Multipath TC= P to wireless access networks with overlapping coverage area, and it discusses potential protocol extensions that aim to improve operation in such environments.  The analysis attempts to identify use cases, benefits a= s well as technical and functional obstacles encountered in the current versi= on of the protocol.  Based on this analysis, recommendations are made on feature-, signaling- and policy extensions that promise to enhance Multipath-TCP's value, versatility and market acceptance in wireless access networks.

 

 

IMPORTANT COMMENTS: Apart from a variety of recommendati= ons for research, the I-D proposes the following signaling and policy enhanceme= nts:

 

MP_SELECT option:

The host sends this option to enforce path-selective operation on its peer.  The option is generally sent on the subflow to= be used for data transmission. It may enclose an address id in case it is sent= on another subflow, e.g. in break-before-make scenarios before the designated = path becomes available. The option permits low-complexity MPTCP receiver solutio= ns (Section 4.4) as well as dynamic overhead shedding for heavily loaded serve= rs (Section 4.5).

 

AVAIL_ADDR/UNAVAIL_ADDR option(s):

The host sends this option to inform its peer about the availability/unavailability status of an interface referred to via an addre= ss id.  The enclosed address-id permits sending the option from an availa= ble interface to refer to an unavailable interface. The option permits the peer= to swiftly adjust data transmission when the host’s interface availabili= ty changes. There are multiple use cases for this option (Section 3.6, Section= 4.4 and Section 4.5).

 

DEFER_ADDR option:

The host sends this option to instruct its peer to use a specific address referred to via an address id as the destination for all future subflows. This option is required for transparent-proxy operation (section 5).

 

ADD_ADDR option:

The present version of this option should be modified: T= he option should only provide a mapping between address id and address value without further advice or request for action. When the ADD_ADDRESS option refers to the source address of the packet it is enclosed in, it can omit t= he address value. The re-interpretation of this option is necessary to support multiple instructions as provided by the options above (and the one below).=

 

JOIN_ADDR option:

The host sends this option to request subflow creation (= via MP_JOIN) to an address referred to via the enclosed address id. Currently, = the functionality of this option is melted into the ADD_ADDR option.=

 

DSS insertion policy for bulk transfer:

To reduce receiver complexity, DSS options should be inserted into all packets of a bulk until the first data ACK is received fo= r a packet contained in the bulk (Section 3.7).

 

 

Please take the details from t= he corresponding sections of the document. Comments are welcome. Thank you.

 

Regards,

Georg Hampel=

 

 

 

--_000_154773479ED2314980CB638A48FC443484DC89D5USNAVSXCHMBSA2n_-- From georg.hampel@alcatel-lucent.com Tue Jun 21 08:57:38 2011 Return-Path: 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 2C8D411E8276 for ; Tue, 21 Jun 2011 08:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xs7-k8jGcgtT for ; Tue, 21 Jun 2011 08:57:37 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4B94711E828C for ; Tue, 21 Jun 2011 08:57:36 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p5LFvZVL008713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jun 2011 10:57:36 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5LFvY1p018648 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Jun 2011 10:57:34 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 21 Jun 2011 10:57:35 -0500 From: "Hampel, K Georg (K Georg)" To: "christoph.paasch@uclouvain.be" , "multipathtcp@ietf.org" Date: Tue, 21 Jun 2011 10:57:33 -0500 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: AcwwBFlmwpW3XaGERMilI3uMy6//swAJb77g Message-ID: <154773479ED2314980CB638A48FC443484DC89F3@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D15D18D@rsys005a.comm.ad.roke.co.uk> <201106211314.04612.christoph.paasch@uclouvain.be> In-Reply-To: <201106211314.04612.christoph.paasch@uclouvain.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:57:38 -0000 Hello Christoph, You are right! I have overseen this. Thanks. Georg -----Original Message----- From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be]=20 Sent: Tuesday, June 21, 2011 7:14 AM To: multipathtcp@ietf.org Cc: Ford, Alan; Hampel, K Georg (K Georg); Klein, Thierry E (Thierry) Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi all, I took also some time to read the draft and have some comments on your draf= t=20 and on Alan's comments. 3.6: "The ADD_ADDR option can be simplified when it refers to the packet's sourc= e=20 address." I don't see a case where the ADD_ADDR-option is sent, refering to the packe= t's=20 source address, because the address-id of this source-address has already b= een=20 provided by the MP_JOIN when establishing the subflow. On Tuesday 21 June 2011 wrote Ford, Alan: > 3.7: This idea is sensible, but I would be reluctant to mandate it. I > think some text like this may be sufficient: "An implementation SHOULD > send DSS options that cover multiple segments multiple times, to reduce > the need for unnecessary buffering at the receiver. It is RECOMMENDED > that a sender repeats the DSS option until a DATA ACK for some data > covered by this mapping is received." In fact, if the first packet (carrying the DSS) is lost, packets will be=20 stored in the subflow-specific out-of-order queue, because we have a loss a= t=20 the subflow-level. In any case, as long as the whole mapping of the payload has not been=20 received, we need to buffer the packets for the checksum-verification. 4.3: "In case the old subflow becomes unavailable, retransmissions can..." Maybe you should note, that the retransmissions have to be done on the new= =20 subflow before the regular data-stream. Otherwise you might have problems, = in=20 the next paragraph. Concerning your removal of the DSS-options. Is it intended that after remov= ing=20 the DSS-options the host is still able to switch to another subflow? If this is the case, then we have problems with middleboxes modifying the=20 content of packets (e.g., IP-address rewriting). If they add/remove a byte,= =20 the data-sequence mapping between the two hosts isn't the same anymore. 4.3: "Using only one flow/congestion engine significantly..." So, the intention is to have the same congestion-window and slow-start- threshhold on the new subflow as on the old-one, and thus you do not slow- start on the new subflow? I'm not sure if this is a good idea. You will probably overload the network= in=20 the beginning. It may also be, that statefull firewalls are dropping packet= s,=20 because they do not fit in the expected window. > "Path Availability" - this is where I get confused as to what the goal > of this is. Can you give an example scenario where this would be useful? >=20 > Throughout the rest of this document, I struggle to see what difference > there is between path (or interface) availability, and address > availability. We have the ADD_ADDR and REMOVE_ADDR options to indicate > the availability or loss of availability of an address (interface) on a > host. What is (UN)AVAIL_ADDR giving over and above this? Why separate > the creation of the mapping and the signalling of the availability? Agree with Alan on this point. I don't really see the difference between=20 ADD/REMOVE and AVAIL/UNAVAIL. 4.4.2: "Obviously, the host most have announced the mapping between address id and= =20 address value prior to the handover using the ADD_ADDRESS option." Here, we are in the BBM-scenario. Thus, we do not yet have the new address.= So=20 we cannot announce it with ADD_ADDR, because we don't know which address we= =20 will get. Cheers, Christoph -- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp Universit=E9 Catholique de Louvain www.rollerbulls.be -- From prvs=1153d46856=alan.ford@roke.co.uk Tue Jun 21 09:34:33 2011 Return-Path: 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 E575211E8281 for ; Tue, 21 Jun 2011 09:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5owMpKqy4gz for ; Tue, 21 Jun 2011 09:34:25 -0700 (PDT) Received: from gse-mta-29.emailfiltering.com (gse-mta-29-tx.emailfiltering.com [194.116.198.160]) by ietfa.amsl.com (Postfix) with ESMTP id 1357611E8282 for ; Tue, 21 Jun 2011 09:34:23 -0700 (PDT) Received: from salt-ext.roke.co.uk ([109.207.29.2]) by gse-mta-29.emailfiltering.com with emfmta (version 4.8.2.32) vanilla id 442005400 for multipathtcp@ietf.org; e8a5473df180bca0; Tue, 21 Jun 2011 17:34:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC3031.12E5F250" Date: Tue, 21 Jun 2011 17:34:21 +0100 Message-ID: <2181C5F19DD0254692452BFF3EAF1D680D15D4D9@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <154773479ED2314980CB638A48FC443484DC89D5@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: AcwsNoAEwA+vzYT/SF6zM7ztidT2sgDuBMNgAAwbvkAAA1GVcA== References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D15D18D@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443484DC89D5@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> From: "Ford, Alan" To: "Hampel, K Georg \(K Georg\)" , Cc: "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 16:34:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3031.12E5F250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Georg, all, =20 To extract two key points from your mail below: =20 [G.H.] The "Path availability" option shows up in sections 3.6 and 4.4.2. Here is an example that applies to section 3.6: =20 A multi-homed mobile downloads a data stream from a server using 2 interfaces, say, Wifi & 4G. Suddenly, a lower-layer signal on the mobile indicates that the 4G interface has dropped off (coverage hole or fade). The server does not know about this signal and keeps pumping data along both paths. The data sent to the Wifi interface arrive but they cannot get delivered since all 4G-data get dropped. When RTO is exceeded for the 4G path, the server starts to realize that something is wrong and engages into retransmission, most likely on the same subflow first and after even more time, it engages into cross-subflow retransmission (dependent on local policy).=20 The whole mess could get resolved much faster if the mobile quickly informed the server about the sudden unavailability of its 4G interface. In this case, the server would be certain within 1/2 RTT that the "4G" interface is currently NOT good and it can immediately redirect all data including 4G-retransmissions to the "WiFi" path. The mobile should NOT tear down the "4G" path since it can be back up any moment. Further, MP_PRIO cannot be used since it cannot be sent on an unavailable path. Moreover, the MP_PRIO refers to individual paths, while the present problem applies to a specific interface, i.e. which may affect multiple paths. =20 Whilst I understand the case you are describing here, I think you may be underestimating the flexibility that could be implemented in the MPTCP retransmission algorithm. At the moment , we do not have any significant retransmission recommendations since we have relatively little real-world experience to base it on. But an aggressive retransmission strategy would cope with this scenario quite well. For example, if the Wifi continues well, there will soon be a point where the buffer is rapidly filling at the receiver and the discrepancy between the DATA_ACK and the subflow ACK is large enough to trigger a retransmission on the functioning subflow. (This should probably not exceed max(RTT), given the receive buffer sizing). =20 [G.H.] We had an MPTCP mailing list discussion on BBM. From this discussion I understand that BBM on lower layer should NOT be followed on L4. The reasons given were: When a host with one radio interface rapidly ping-pongs between two networks (lower-layer BBM at every switch), MPTCP should keep both subflows up and solely change the activity of each path. In other words, BBM on lower layers is translated to MBB on MPTCP. Your proposal, i.e. sending FIN on the old path, would make a switchback to the old path very slow (since you have to MP_JOIN again). Further, the remote peer may not respond to FIN if it still has data to send (!). The BBM ping-pong scenario is another reason for AVAIL/UNAVAIL_ADDR. =20 In this case, you are relying on the wireless network infrastructure retaining state (i.e. NATs) for the connection while the host uses another network. This is by no means guaranteed, and will require an adjustment to the subflow-level state machines at each host, to determine that a lost packet on an interface is not cause for terminating a subflow when that same connection-level data has since been successfully transmitted on another subflow (if this was applied, however, the desired result could be achieved with a MP_PRIO signal either downgrading the background subflow or promoting the foreground one to be the "use me and me alone" subflow). =20 If we were to modify the MP_PRIO option to take an Address ID (which is something we've thought about doing before but the use cases were not clear), then you could downgrade one path from another. That may be sufficient (at least, with tolerant flow control). Shortcuts of a second bit to say "Do not use" or "use exclusively" could also help here. Might this cover all cases? =20 Regards, Alan =20 =20 From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com] Sent: 21 June 2011 16:44 To: Ford, Alan; multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks =20 Hello Alan, =20 Thanks for reading the draft. We are currently implementing a low-complexity MPTCP version for path-selective mode (see section 4 of draft). Many of the issues in section 4 came up when we thought through the specific steps for such a design. There are multiple ways to tackle these issues. I have added comments below. =20 Regards, Georg =20 ________________________________ From: Ford, Alan [mailto:alan.ford@roke.co.uk]=20 Sent: Tuesday, June 21, 2011 5:50 AM To: Hampel, K Georg (K Georg); multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks =20 Hello Georg, Thierry, =20 Thanks for writing this - it covers an important and interesting topic. I've had a chance to read it, now, and have some comments. =20 3.3: It is definitely intentional that you can use MPTCP with no changes to send data resiliently on many paths. I'll expand the text in the protocol draft slightly to discuss processing the same mappings on different subflows. =20 3.4: Agreed, this (fluctuations in path throughput/delay) is a very valid concern and one that we discuss considerably in the API draft. It is an issue where users are best placed to drive the development of solutions. =20 3.7: This idea is sensible, but I would be reluctant to mandate it. I think some text like this may be sufficient: "An implementation SHOULD send DSS options that cover multiple segments multiple times, to reduce the need for unnecessary buffering at the receiver. It is RECOMMENDED that a sender repeats the DSS option until a DATA ACK for some data covered by this mapping is received." =20 "Path Availability" - this is where I get confused as to what the goal of this is. Can you give an example scenario where this would be useful? Throughout the rest of this document, I struggle to see what difference there is between path (or interface) availability, and address availability. We have the ADD_ADDR and REMOVE_ADDR options to indicate the availability or loss of availability of an address (interface) on a host. What is (UN)AVAIL_ADDR giving over and above this? Why separate the creation of the mapping and the signalling of the availability? =20 [G.H.] The "Path availability" option shows up in sections 3.6 and 4.4.2. Here is an example that applies to section 3.6: =20 A multi-homed mobile downloads a data stream from a server using 2 interfaces, say, Wifi & 4G. Suddenly, a lower-layer signal on the mobile indicates that the 4G interface has dropped off (coverage hole or fade). The server does not know about this signal and keeps pumping data along both paths. The data sent to the Wifi interface arrive but they cannot get delivered since all 4G-data get dropped. When RTO is exceeded for the 4G path, the server starts to realize that something is wrong and engages into retransmission, most likely on the same subflow first and after even more time, it engages into cross-subflow retransmission (dependent on local policy).=20 The whole mess could get resolved much faster if the mobile quickly informed the server about the sudden unavailability of its 4G interface. In this case, the server would be certain within 1/2 RTT that the "4G" interface is currently NOT good and it can immediately redirect all data including 4G-retransmissions to the "WiFi" path. The mobile should NOT tear down the "4G" path since it can be back up any moment. Further, MP_PRIO cannot be used since it cannot be sent on an unavailable path. Moreover, the MP_PRIO refers to individual paths, while the present problem applies to a specific interface, i.e. which may affect multiple paths. =20 Some points on 4.4: =20 Yes, MP_PRIO is not binding, although the expectation is that a host should have a good reason for ignoring it (such as if the path appears dead to the host, or it costs too much money) - I can't see that we can change that. If an end host was desperate to stop receiving traffic on an interface, it could drop the subflow. =20 If I understand your comment correctly, you'd like to be able to switch a single path to B=3D0 and all the others to B=3D1 in one go, and this = is the purpose of MP_SELECT? I guess we could adapt MP_PRIO to achieve this, by having another value that means "use me and me alone". Although I think I need more convincing that it adds value! =20 [G.H] I think you summarized the essence of MP_SELECT rather well. There are multiple ways of doing this. The goal of all this is that the host can ENFORCE path-selective operation on the peer's sender since this simplifies the host's receiver, AND that path-reselection can be done in the FASTEST and MOST RELIABLE possible way. Constraints are: (1) MP_PRIO with B=3D1 cannot be sent on a path that is already down, (2) = uncertainty when multiple MP_PRIO message with different B-setting arrive out of sync due to the different RTTs on the various paths, (3) conflict resolution, i.e. host A wants receive data on path 1 but host B wants to send data on path 2, (4) long delay in case "switching messages" get lost. =20 In 4.4.2, you talk about BBM in the scenario of a radio knowing that it is going to take down its interface to attach to a new network. You can do this already cleanly - just FIN the old path (without a DATA FIN) and bring up the new one. What is your proposal adding? =20 [G.H.] We had an MPTCP mailing list discussion on BBM. From this discussion I understand that BBM on lower layer should NOT be followed on L4. The reasons given were: When a host with one radio interface rapidly ping-pongs between two networks (lower-layer BBM at every switch), MPTCP should keep both subflows up and solely change the activity of each path. In other words, BBM on lower layers is translated to MBB on MPTCP. Your proposal, i.e. sending FIN on the old path, would make a switchback to the old path very slow (since you have to MP_JOIN again). Further, the remote peer may not respond to FIN if it still has data to send (!). The BBM ping-pong scenario is another reason for AVAIL/UNAVAIL_ADDR. =20 =20 5.1 is an interesting problem and one that Mark led some discussion of at the last IETF. As with the discussion about AVAIL_ADDR, I don't see the point of JOIN_ADDR and ADD_ADDR separations, but DEFER_ADDR (or "USE_THIS_ADDR!") is an interesting idea that I need to think about some more! =20 [G.H.] I think Mark had a more generic proxy solution in mind. The "transparent" proxy we are proposing has much more stringent deployment requirements. However, there is a very important use case (put it on PDN-GW) and it can be realized through a very simple signalling enhancement ("USE_THIS_ADDR" may indeed be clearer). =20 Regards, Alan =20 From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Hampel, K Georg (K Georg) Sent: 16 June 2011 16:03 To: multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks =20 All, =20 We have uploaded a new I-D. =20 Title: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks =20 Authors: Georg Hampel, Thierry Klein =20 Filename: draft-hampel-mptcp-applicability-wireless-networks-00.txt =20 URL: http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-wireles s-networks/ =20 Abstract: This document analyses the applicability of Multipath TCP to wireless access networks with overlapping coverage area, and it discusses potential protocol extensions that aim to improve operation in such environments. The analysis attempts to identify use cases, benefits as well as technical and functional obstacles encountered in the current version of the protocol. Based on this analysis, recommendations are made on feature-, signaling- and policy extensions that promise to enhance Multipath-TCP's value, versatility and market acceptance in wireless access networks. =20 =20 IMPORTANT COMMENTS: Apart from a variety of recommendations for research, the I-D proposes the following signaling and policy enhancements:=20 =20 MP_SELECT option: The host sends this option to enforce path-selective operation on its peer. The option is generally sent on the subflow to be used for data transmission. It may enclose an address id in case it is sent on another subflow, e.g. in break-before-make scenarios before the designated path becomes available. The option permits low-complexity MPTCP receiver solutions (Section 4.4) as well as dynamic overhead shedding for heavily loaded servers (Section 4.5). =20 AVAIL_ADDR/UNAVAIL_ADDR option(s): The host sends this option to inform its peer about the availability/unavailability status of an interface referred to via an address id. The enclosed address-id permits sending the option from an available interface to refer to an unavailable interface. The option permits the peer to swiftly adjust data transmission when the host's interface availability changes. There are multiple use cases for this option (Section 3.6, Section 4.4 and Section 4.5). =20 DEFER_ADDR option:=20 The host sends this option to instruct its peer to use a specific address referred to via an address id as the destination for all future subflows. This option is required for transparent-proxy operation (section 5). =20 ADD_ADDR option: The present version of this option should be modified: The option should only provide a mapping between address id and address value without further advice or request for action. When the ADD_ADDRESS option refers to the source address of the packet it is enclosed in, it can omit the address value. The re-interpretation of this option is necessary to support multiple instructions as provided by the options above (and the one below). =20 JOIN_ADDR option:=20 The host sends this option to request subflow creation (via MP_JOIN) to an address referred to via the enclosed address id. Currently, the functionality of this option is melted into the ADD_ADDR option. =20 DSS insertion policy for bulk transfer:=20 To reduce receiver complexity, DSS options should be inserted into all packets of a bulk until the first data ACK is received for a packet contained in the bulk (Section 3.7). =20 =20 Please take the details from the corresponding sections of the document. Comments are welcome. Thank you. =20 Regards, Georg Hampel =20 =20 =20 ------_=_NextPart_001_01CC3031.12E5F250 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Georg, all,

 

To extract two key points from your mail below:

 

[G.H.] The “Path availability” option shows up = in sections 3.6 and 4.4.2. Here is an example that applies to section = 3.6:

 

A multi-homed mobile downloads a data stream from a server = using 2 interfaces, say,  Wifi & 4G. Suddenly, a lower-layer signal on = the mobile indicates that the 4G interface has dropped off (coverage hole or = fade). The server does not know about this signal and keeps pumping data along = both paths. The data sent to the Wifi interface arrive but they cannot get = delivered since all 4G-data get dropped. When RTO is exceeded for the 4G path, the = server starts to realize that something is wrong and engages into = retransmission, most likely on the same subflow first and after even more time, it engages = into cross-subflow retransmission (dependent on local policy). =

The whole mess could get resolved much faster if the mobile = quickly informed the server about the sudden unavailability of its 4G interface. = In this case, the server would be certain within 1/2 RTT that the = “4G” interface is currently NOT good and it can immediately redirect all data including 4G-retransmissions to the “WiFi” path. The mobile = should NOT tear down the “4G” path since it can be back up any = moment. Further, MP_PRIO cannot be used since it cannot be sent on an = unavailable path. Moreover, the MP_PRIO refers to individual paths, while the present = problem applies to a specific interface, i.e. which may affect multiple = paths.

 

Whilst I understand the case you are describing here, I think you may be underestimating the flexibility that could be implemented in the MPTCP retransmission algorithm.  At the moment , we do not have any = significant retransmission recommendations since we have relatively little = real-world experience to base it on.  But an aggressive retransmission = strategy would cope with this scenario quite well.  For example, if the Wifi = continues well, there will soon be a point where the buffer is rapidly filling at = the receiver and the discrepancy between the DATA_ACK and the subflow ACK is = large enough to trigger a retransmission on the functioning subflow. (This = should probably not exceed max(RTT), given the receive buffer = sizing).

 

[G.H.] We had an MPTCP mailing list discussion on BBM. From = this discussion I understand that BBM on lower layer should NOT be followed = on L4. The reasons given were: When a host with one radio interface rapidly = ping-pongs between two networks (lower-layer BBM at every switch), MPTCP should = keep both subflows up and solely change the activity of each path. In other words, BBM on = lower layers is translated to MBB on MPTCP. Your proposal, i.e. sending FIN on = the old path, would make a switchback to the old path very slow (since you = have to MP_JOIN again). Further, the remote peer may not respond to FIN if it = still has data to send (!). The BBM ping-pong scenario is another reason for AVAIL/UNAVAIL_ADDR.

 

In this case, you are relying on the wireless network infrastructure = retaining state (i.e.  NATs) for the connection while the host uses another = network.  This is by no means guaranteed, and will require an adjustment to the = subflow-level state machines at each host, to determine that a lost packet on an = interface is not cause for terminating a subflow when that same connection-level data = has since been successfully transmitted on another subflow (if this was = applied, however, the desired result could be achieved with a MP_PRIO signal = either downgrading the background subflow or promoting the foreground one to be = the “use me and me alone” subflow).

 

If we were to modify the MP_PRIO option to take an Address ID (which is = something we’ve thought about doing before but the use cases were not = clear), then you could downgrade one path from another. That may be sufficient (at = least, with tolerant flow control).  Shortcuts of a second bit to say = “Do not use” or “use exclusively” could also help = here.  Might this cover all cases?

 

Regards,<= /o:p>

Alan

 

 

From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com]
Sent: 21 June 2011 16:44
To: Ford, Alan; multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierry)
Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access = Networks

 

Hello Alan,

 

Thanks for reading the draft.  We are currently = implementing a low-complexity MPTCP version for path-selective mode (see section 4 of = draft). Many of the issues in section 4 came up when we thought through the = specific steps for such a design. There are multiple ways to tackle these issues. = I have added comments below.

 

Regards,

Georg

 

From: Ford, Alan = [mailto:alan.ford@roke.co.uk]
Sent: Tuesday, June 21, 2011 5:50 AM
To: Hampel, K Georg (K Georg); multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierry)
Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

 

Hello Georg, Thierry,

 

Thanks for writing this – it covers an important and interesting topic. I’ve had a chance to read it, now, and have some = comments.

 

3.3: It is definitely intentional that you can use MPTCP with no changes to = send data resiliently on many paths. I’ll expand the text in the = protocol draft slightly to discuss processing the same mappings on different = subflows.

 

3.4: Agreed, this (fluctuations in path throughput/delay) is a very valid = concern and one that we discuss considerably in the API draft.  It is an = issue where users are best placed to drive the development of = solutions.

 

3.7: This idea is sensible, but I would be reluctant to mandate it.  I = think some text like this may be sufficient: “An implementation SHOULD = send DSS options that cover multiple segments multiple times, to reduce the need = for unnecessary buffering at the receiver.  It is RECOMMENDED that a = sender repeats the DSS option until a DATA ACK for some data covered by this = mapping is received.”

 

“Path Availability” – this is where I get confused as to what the = goal of this is. Can you give an example scenario where this would be = useful?

Throughout the rest of this document, I struggle to see what difference there is = between path (or interface) availability, and address availability.  We = have the ADD_ADDR and REMOVE_ADDR options to indicate the availability or loss of availability of an address (interface) on a host.  What is = (UN)AVAIL_ADDR giving over and above this? Why separate the creation of the mapping and = the signalling of the availability?

 

[G.H.] The “Path availability” option shows up = in sections 3.6 and 4.4.2. Here is an example that applies to section = 3.6:

 

A multi-homed mobile downloads a data stream from a server = using 2 interfaces, say,  Wifi & 4G. Suddenly, a lower-layer signal on = the mobile indicates that the 4G interface has dropped off (coverage hole or = fade). The server does not know about this signal and keeps pumping data along = both paths. The data sent to the Wifi interface arrive but they cannot get = delivered since all 4G-data get dropped. When RTO is exceeded for the 4G path, the = server starts to realize that something is wrong and engages into = retransmission, most likely on the same subflow first and after even more time, it engages = into cross-subflow retransmission (dependent on local policy). =

The whole mess could get resolved much faster if the mobile = quickly informed the server about the sudden unavailability of its 4G interface. = In this case, the server would be certain within 1/2 RTT that the = “4G” interface is currently NOT good and it can immediately redirect all data including 4G-retransmissions to the “WiFi” path. The mobile = should NOT tear down the “4G” path since it can be back up any = moment. Further, MP_PRIO cannot be used since it cannot be sent on an = unavailable path. Moreover, the MP_PRIO refers to individual paths, while the present = problem applies to a specific interface, i.e. which may affect multiple = paths.

 

Some points on 4.4:

 

Yes, MP_PRIO is not binding, although the expectation is that a host should = have a good reason for ignoring it (such as if the path appears dead to the = host, or it costs too much money) – I can’t see that we can change = that.  If an end host was desperate to stop receiving traffic on an = interface, it could drop the subflow.

 

If I understand your comment correctly, you’d like to be able to = switch a single path to B=3D0 and all the others to B=3D1 in one go, and this is = the purpose of MP_SELECT?  I guess we could adapt MP_PRIO to achieve this, by = having another value that means “use me and me alone”.  = Although I think I need more convincing that it adds value!

 

[G.H] I think you summarized the essence of MP_SELECT rather = well. There are multiple ways of doing this. The goal of all this is that the = host can ENFORCE path-selective operation on the peer’s sender since = this simplifies the host’s receiver, AND that path-reselection can be = done in the FASTEST and MOST RELIABLE possible way. Constraints are: (1) MP_PRIO = with B=3D1 cannot be sent on a path that is already down, (2) uncertainty = when multiple MP_PRIO message with different B-setting arrive out of sync due = to the different RTTs on the various paths, (3) conflict resolution, i.e. host = A wants receive data on path 1 but host B wants to send data on path 2, (4) long = delay in case “switching messages” get lost.

 

In 4.4.2, you talk about BBM in the scenario of a radio knowing that = it is going to take down its interface to attach to a new network.  You = can do this already cleanly – just FIN the old path (without a DATA FIN) = and bring up the new one.  What is your proposal = adding?

 =

[G.H.] We had an MPTCP mailing list discussion on BBM. From = this discussion I understand that BBM on lower layer should NOT be followed = on L4. The reasons given were: When a host with one radio interface rapidly = ping-pongs between two networks (lower-layer BBM at every switch), MPTCP should = keep both subflows up and solely change the activity of each path. In other words, BBM on = lower layers is translated to MBB on MPTCP. Your proposal, i.e. sending FIN on = the old path, would make a switchback to the old path very slow (since you = have to MP_JOIN again). Further, the remote peer may not respond to FIN if it = still has data to send (!). The BBM ping-pong scenario is another reason for AVAIL/UNAVAIL_ADDR.

 

 

5.1 is an interesting problem and one that Mark led some discussion of at = the last IETF.  As with the discussion about AVAIL_ADDR, I don’t see = the point of JOIN_ADDR and ADD_ADDR separations, but DEFER_ADDR (or “USE_THIS_ADDR!”) is an interesting idea that I need to = think about some more!

 

[G.H.] I think Mark had a more generic proxy solution in = mind. The “transparent” proxy we are proposing has much more stringent deployment requirements. However, there is a very important use case = (put it on PDN-GW) and it can be realized through a very simple signalling = enhancement (“USE_THIS_ADDR” may indeed be = clearer).

 

Regards,<= /o:p>

Alan

 

From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Hampel, K = Georg (K Georg)
Sent: 16 June 2011 16:03
To: multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierry)
Subject: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access = Networks

 

All,

 
= 
We have uploaded =
a new I-D.
 
= 
Title: =
Enhancements to Improve the Applicability of Multipath TCP to Wireless =
Access Networks

 

Authors: = Georg Hampel, Thierry Klein

 

Filename: =
draft-hampel-mptcp-applicability-wireless-networks-00.txt

 

URL: http://datatracker.ietf.org/doc/draft-hampel-mptcp-ap= plicability-wireless-networks/

 

Abstract:

This document analyses the applicability of Multipath TCP to wireless access networks with overlapping coverage area, and it discusses potential = protocol extensions that aim to improve operation in such environments.  The analysis attempts to identify use cases, benefits as well as technical = and functional obstacles encountered in the current version of the = protocol.  Based on this analysis, recommendations are made on feature-, signaling- = and policy extensions that promise to enhance Multipath-TCP's value, = versatility and market acceptance in wireless access networks.

 

 

IMPORTANT COMMENTS: Apart from a variety of recommendations for research, the I-D proposes the following signaling and policy enhancements: =

 

MP_SELECT option:

The host sends this option to enforce path-selective operation on its = peer.  The option is generally sent on the subflow to be used for data = transmission. It may enclose an address id in case it is sent on another subflow, e.g. = in break-before-make scenarios before the designated path becomes = available. The option permits low-complexity MPTCP receiver solutions (Section 4.4) as = well as dynamic overhead shedding for heavily loaded servers (Section = 4.5).

 

AVAIL_ADDR/UNAVAIL_ADDR option(s):

The host sends this option to inform its peer about the = availability/unavailability status of an interface referred to via an address id.  The enclosed address-id permits sending the option from an available interface to = refer to an unavailable interface. The option permits the peer to swiftly adjust = data transmission when the host’s interface availability changes. There = are multiple use cases for this option (Section 3.6, Section 4.4 and Section = 4.5).

 

DEFER_ADDR option:

The host sends this option to instruct its peer to use a specific address = referred to via an address id as the destination for all future subflows. This = option is required for transparent-proxy operation (section = 5).

 

ADD_ADDR option:

The present version of this option should be modified: The option should = only provide a mapping between address id and address value without further = advice or request for action. When the ADD_ADDRESS option refers to the source = address of the packet it is enclosed in, it can omit the address value. The re-interpretation of this option is necessary to support multiple = instructions as provided by the options above (and the one = below).

 

JOIN_ADDR option:

The host sends this option to request subflow creation (via MP_JOIN) to an = address referred to via the enclosed address id. Currently, the functionality of = this option is melted into the ADD_ADDR option.

 

DSS insertion policy for bulk transfer:

To reduce receiver complexity, DSS options should be inserted into all = packets of a bulk until the first data ACK is received for a packet contained in = the bulk (Section 3.7).

 

 

Please take = the details from the corresponding sections of the document. Comments are = welcome. Thank you.

 

Regards,=

Georg = Hampel

 

 

 

------_=_NextPart_001_01CC3031.12E5F250-- From touch@isi.edu Tue Jun 21 09:39:39 2011 Return-Path: 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 0DFA311E8296 for ; Tue, 21 Jun 2011 09:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98Yd2cx3YD9H for ; Tue, 21 Jun 2011 09:39:38 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9777F11E8282 for ; Tue, 21 Jun 2011 09:39:38 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p5LGcwEU015159 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 21 Jun 2011 09:38:58 -0700 (PDT) Message-ID: <4E00C922.6090202@isi.edu> Date: Tue, 21 Jun 2011 09:38:58 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Ford, Alan" References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D15D18D@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D680D15D18D@rsys005a.comm.ad.roke.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org, "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 16:39:39 -0000 Interesting draft, but this - like the original work - continues to confuse IP addresses with paths. I raised this point many times during the original multipath discussion, but it continues to be lost at each successive addition to the work - partly because the work continues to me misnamed "multipathTCP", vs. multiaddressTCP *When* (not if) wireless links are one hop upstream of a device (e.g., in 3G/4G WiFi hotspot boxes), information about an IP address tells you nothing about the availability of the **path**. It'd be useful for this group, esp. those discussing this doc, to consider previous IETF BoF attempts in this area, e.g., trigtran from summer 2003 (unfortunately RFC5184 apparently didn't, since it doesn't address the above limitations unfortunately). Joe From georg.hampel@alcatel-lucent.com Tue Jun 21 12:11:45 2011 Return-Path: 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 94109228011 for ; Tue, 21 Jun 2011 12:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3J4mh90MnOG for ; Tue, 21 Jun 2011 12:11:29 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 722B8228010 for ; Tue, 21 Jun 2011 12:11:27 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p5LJBQa2013490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jun 2011 14:11:26 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5LJBP8G011683 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Jun 2011 14:11:26 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 21 Jun 2011 14:11:25 -0500 From: "Hampel, K Georg (K Georg)" To: "Ford, Alan" , "multipathtcp@ietf.org" Date: Tue, 21 Jun 2011 14:11:24 -0500 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: AcwsNoAEwA+vzYT/SF6zM7ztidT2sgDuBMNgAAwbvkAAA1GVcAAEjstA Message-ID: <154773479ED2314980CB638A48FC443484DC8B19@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D15D18D@rsys005a.comm.ad.roke.co.uk> <154773479ED2314980CB638A48FC443484DC89D5@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D15D4D9@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D680D15D4D9@rsys005a.comm.ad.roke.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC443484DC8B19USNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 19:11:45 -0000 --_000_154773479ED2314980CB638A48FC443484DC8B19USNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alan, all, On address availability: I think we agree that this applies to situations where the host has knowled= ge from lower-layer signaling that one of its links is down or has insuffic= ient "link quality". (This does not necessarily mean that the IP address is= down.) Presently, the host has no means to inform its peer about this know= ledge. If the MP_PRIO message could be equipped with an address-id, as you = suggested, the host could forward this knowledge via another path pertainin= g to an interface that is up and has sufficient link quality. This would ta= ke 1/2RTT. It may be possible that an aggressive cross-subflow retransmissi= on schedule would lead to similar performance. This, however, is currently = unknown. Enforcement of path-selective operation for host with simplified receiver: = When the host wishes to hand over from one of its interfaces (old) to anoth= er (new), the host sends two MP_PRIO options, where one has B=3D1 and refer= s to the old interface (implicitly or via address id) and the other has B= =3D0 and refers to the new path (implicitly or via address id). The host MA= Y send both options on the same path to ensure that they arrive at the same= time. The host MAY enclose these options onto every subsequent packet unti= l it receives the first packet on the new path. This allows the host to ens= ure fast and reliable delivery. In case of conflicts, i.e. the peer does not like the new path, it can simp= ly respond with its own MP_PRIO message-pair to choose another path. To avo= id ping-ponging, the unhappy peer should pick a path that holds the host's = new interface. In summary: The address-id-equipped MP_PRIO option should do the job. On BBM: You are bringing up a good point. Given the uncertainty about middle-box st= ate on a link that has been broken, the host is best advised to discontinue= all subflows pertaining to this broken link. I sent a question on the ML s= ome weeks ago: In case of an imminent BBM, should a host terminate all affe= cted subflows via RST as a courtesy to clear middleboxes? Thanks, Regards, Georg ________________________________ From: Ford, Alan [mailto:alan.ford@roke.co.uk] Sent: Tuesday, June 21, 2011 12:34 PM To: Hampel, K Georg (K Georg); multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi Georg, all, To extract two key points from your mail below: [G.H.] The "Path availability" option shows up in sections 3.6 and 4.4.2. H= ere is an example that applies to section 3.6: A multi-homed mobile downloads a data stream from a server using 2 interfac= es, say, Wifi & 4G. Suddenly, a lower-layer signal on the mobile indicates= that the 4G interface has dropped off (coverage hole or fade). The server = does not know about this signal and keeps pumping data along both paths. Th= e data sent to the Wifi interface arrive but they cannot get delivered sinc= e all 4G-data get dropped. When RTO is exceeded for the 4G path, the server= starts to realize that something is wrong and engages into retransmission,= most likely on the same subflow first and after even more time, it engages= into cross-subflow retransmission (dependent on local policy). The whole mess could get resolved much faster if the mobile quickly informe= d the server about the sudden unavailability of its 4G interface. In this c= ase, the server would be certain within 1/2 RTT that the "4G" interface is = currently NOT good and it can immediately redirect all data including 4G-re= transmissions to the "WiFi" path. The mobile should NOT tear down the "4G" = path since it can be back up any moment. Further, MP_PRIO cannot be used si= nce it cannot be sent on an unavailable path. Moreover, the MP_PRIO refers = to individual paths, while the present problem applies to a specific interf= ace, i.e. which may affect multiple paths. Whilst I understand the case you are describing here, I think you may be un= derestimating the flexibility that could be implemented in the MPTCP retran= smission algorithm. At the moment , we do not have any significant retrans= mission recommendations since we have relatively little real-world experien= ce to base it on. But an aggressive retransmission strategy would cope wit= h this scenario quite well. For example, if the Wifi continues well, there= will soon be a point where the buffer is rapidly filling at the receiver a= nd the discrepancy between the DATA_ACK and the subflow ACK is large enough= to trigger a retransmission on the functioning subflow. (This should proba= bly not exceed max(RTT), given the receive buffer sizing). [G.H.] We had an MPTCP mailing list discussion on BBM. From this discussion= I understand that BBM on lower layer should NOT be followed on L4. The rea= sons given were: When a host with one radio interface rapidly ping-pongs be= tween two networks (lower-layer BBM at every switch), MPTCP should keep bot= h subflows up and solely change the activity of each path. In other words, = BBM on lower layers is translated to MBB on MPTCP. Your proposal, i.e. send= ing FIN on the old path, would make a switchback to the old path very slow = (since you have to MP_JOIN again). Further, the remote peer may not respond= to FIN if it still has data to send (!). The BBM ping-pong scenario is ano= ther reason for AVAIL/UNAVAIL_ADDR. In this case, you are relying on the wireless network infrastructure retain= ing state (i.e. NATs) for the connection while the host uses another netwo= rk. This is by no means guaranteed, and will require an adjustment to the = subflow-level state machines at each host, to determine that a lost packet = on an interface is not cause for terminating a subflow when that same conne= ction-level data has since been successfully transmitted on another subflow= (if this was applied, however, the desired result could be achieved with a= MP_PRIO signal either downgrading the background subflow or promoting the = foreground one to be the "use me and me alone" subflow). If we were to modify the MP_PRIO option to take an Address ID (which is som= ething we've thought about doing before but the use cases were not clear), = then you could downgrade one path from another. That may be sufficient (at = least, with tolerant flow control). Shortcuts of a second bit to say "Do n= ot use" or "use exclusively" could also help here. Might this cover all ca= ses? Regards, Alan From: Hampel, K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com] Sent: 21 June 2011 16:44 To: Ford, Alan; multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hello Alan, Thanks for reading the draft. We are currently implementing a low-complexi= ty MPTCP version for path-selective mode (see section 4 of draft). Many of = the issues in section 4 came up when we thought through the specific steps = for such a design. There are multiple ways to tackle these issues. I have a= dded comments below. Regards, Georg ________________________________ From: Ford, Alan [mailto:alan.ford@roke.co.uk] Sent: Tuesday, June 21, 2011 5:50 AM To: Hampel, K Georg (K Georg); multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hello Georg, Thierry, Thanks for writing this - it covers an important and interesting topic. I'v= e had a chance to read it, now, and have some comments. 3.3: It is definitely intentional that you can use MPTCP with no changes to= send data resiliently on many paths. I'll expand the text in the protocol = draft slightly to discuss processing the same mappings on different subflow= s. 3.4: Agreed, this (fluctuations in path throughput/delay) is a very valid c= oncern and one that we discuss considerably in the API draft. It is an iss= ue where users are best placed to drive the development of solutions. 3.7: This idea is sensible, but I would be reluctant to mandate it. I thin= k some text like this may be sufficient: "An implementation SHOULD send DSS= options that cover multiple segments multiple times, to reduce the need fo= r unnecessary buffering at the receiver. It is RECOMMENDED that a sender r= epeats the DSS option until a DATA ACK for some data covered by this mappin= g is received." "Path Availability" - this is where I get confused as to what the goal of t= his is. Can you give an example scenario where this would be useful? Throughout the rest of this document, I struggle to see what difference the= re is between path (or interface) availability, and address availability. = We have the ADD_ADDR and REMOVE_ADDR options to indicate the availability o= r loss of availability of an address (interface) on a host. What is (UN)AV= AIL_ADDR giving over and above this? Why separate the creation of the mappi= ng and the signalling of the availability? [G.H.] The "Path availability" option shows up in sections 3.6 and 4.4.2. H= ere is an example that applies to section 3.6: A multi-homed mobile downloads a data stream from a server using 2 interfac= es, say, Wifi & 4G. Suddenly, a lower-layer signal on the mobile indicates= that the 4G interface has dropped off (coverage hole or fade). The server = does not know about this signal and keeps pumping data along both paths. Th= e data sent to the Wifi interface arrive but they cannot get delivered sinc= e all 4G-data get dropped. When RTO is exceeded for the 4G path, the server= starts to realize that something is wrong and engages into retransmission,= most likely on the same subflow first and after even more time, it engages= into cross-subflow retransmission (dependent on local policy). The whole mess could get resolved much faster if the mobile quickly informe= d the server about the sudden unavailability of its 4G interface. In this c= ase, the server would be certain within 1/2 RTT that the "4G" interface is = currently NOT good and it can immediately redirect all data including 4G-re= transmissions to the "WiFi" path. The mobile should NOT tear down the "4G" = path since it can be back up any moment. Further, MP_PRIO cannot be used si= nce it cannot be sent on an unavailable path. Moreover, the MP_PRIO refers = to individual paths, while the present problem applies to a specific interf= ace, i.e. which may affect multiple paths. Some points on 4.4: Yes, MP_PRIO is not binding, although the expectation is that a host should= have a good reason for ignoring it (such as if the path appears dead to th= e host, or it costs too much money) - I can't see that we can change that. = If an end host was desperate to stop receiving traffic on an interface, it= could drop the subflow. If I understand your comment correctly, you'd like to be able to switch a s= ingle path to B=3D0 and all the others to B=3D1 in one go, and this is the = purpose of MP_SELECT? I guess we could adapt MP_PRIO to achieve this, by h= aving another value that means "use me and me alone". Although I think I n= eed more convincing that it adds value! [G.H] I think you summarized the essence of MP_SELECT rather well. There ar= e multiple ways of doing this. The goal of all this is that the host can EN= FORCE path-selective operation on the peer's sender since this simplifies t= he host's receiver, AND that path-reselection can be done in the FASTEST an= d MOST RELIABLE possible way. Constraints are: (1) MP_PRIO with B=3D1 canno= t be sent on a path that is already down, (2) uncertainty when multiple MP_= PRIO message with different B-setting arrive out of sync due to the differe= nt RTTs on the various paths, (3) conflict resolution, i.e. host A wants re= ceive data on path 1 but host B wants to send data on path 2, (4) long dela= y in case "switching messages" get lost. In 4.4.2, you talk about BBM in the scenario of a radio knowing that it is = going to take down its interface to attach to a new network. You can do th= is already cleanly - just FIN the old path (without a DATA FIN) and bring u= p the new one. What is your proposal adding? [G.H.] We had an MPTCP mailing list discussion on BBM. From this discussion= I understand that BBM on lower layer should NOT be followed on L4. The rea= sons given were: When a host with one radio interface rapidly ping-pongs be= tween two networks (lower-layer BBM at every switch), MPTCP should keep bot= h subflows up and solely change the activity of each path. In other words, = BBM on lower layers is translated to MBB on MPTCP. Your proposal, i.e. send= ing FIN on the old path, would make a switchback to the old path very slow = (since you have to MP_JOIN again). Further, the remote peer may not respond= to FIN if it still has data to send (!). The BBM ping-pong scenario is ano= ther reason for AVAIL/UNAVAIL_ADDR. 5.1 is an interesting problem and one that Mark led some discussion of at t= he last IETF. As with the discussion about AVAIL_ADDR, I don't see the poi= nt of JOIN_ADDR and ADD_ADDR separations, but DEFER_ADDR (or "USE_THIS_ADDR= !") is an interesting idea that I need to think about some more! [G.H.] I think Mark had a more generic proxy solution in mind. The "transpa= rent" proxy we are proposing has much more stringent deployment requirement= s. However, there is a very important use case (put it on PDN-GW) and it ca= n be realized through a very simple signalling enhancement ("USE_THIS_ADDR"= may indeed be clearer). Regards, Alan From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Hampel, K Georg (K Georg) Sent: 16 June 2011 16:03 To: multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: [multipathtcp] New I-D: Enhancements to Improve the Applicability = of Multipath TCP to Wireless Access Networks All, We have uploaded a new I-D. Title: Enhancements to Improve the Applicability of Multipath TCP to Wirele= ss Access Networks Authors: Georg Hampel, Thierry Klein Filename: draft-hampel-mptcp-applicability-wireless-networks-00.txt URL: http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-wirel= ess-networks/ Abstract: This document analyses the applicability of Multipath TCP to wireless acces= s networks with overlapping coverage area, and it discusses potential proto= col extensions that aim to improve operation in such environments. The ana= lysis attempts to identify use cases, benefits as well as technical and fun= ctional obstacles encountered in the current version of the protocol. Base= d on this analysis, recommendations are made on feature-, signaling- and po= licy extensions that promise to enhance Multipath-TCP's value, versatility = and market acceptance in wireless access networks. IMPORTANT COMMENTS: Apart from a variety of recommendations for research, t= he I-D proposes the following signaling and policy enhancements: MP_SELECT option: The host sends this option to enforce path-selective operation on its peer.= The option is generally sent on the subflow to be used for data transmiss= ion. It may enclose an address id in case it is sent on another subflow, e.= g. in break-before-make scenarios before the designated path becomes availa= ble. The option permits low-complexity MPTCP receiver solutions (Section 4.= 4) as well as dynamic overhead shedding for heavily loaded servers (Section= 4.5). AVAIL_ADDR/UNAVAIL_ADDR option(s): The host sends this option to inform its peer about the availability/unavai= lability status of an interface referred to via an address id. The enclose= d address-id permits sending the option from an available interface to refe= r to an unavailable interface. The option permits the peer to swiftly adjus= t data transmission when the host's interface availability changes. There a= re multiple use cases for this option (Section 3.6, Section 4.4 and Section= 4.5). DEFER_ADDR option: The host sends this option to instruct its peer to use a specific address r= eferred to via an address id as the destination for all future subflows. Th= is option is required for transparent-proxy operation (section 5). ADD_ADDR option: The present version of this option should be modified: The option should on= ly provide a mapping between address id and address value without further a= dvice or request for action. When the ADD_ADDRESS option refers to the sour= ce address of the packet it is enclosed in, it can omit the address value. = The re-interpretation of this option is necessary to support multiple instr= uctions as provided by the options above (and the one below). JOIN_ADDR option: The host sends this option to request subflow creation (via MP_JOIN) to an = address referred to via the enclosed address id. Currently, the functionali= ty of this option is melted into the ADD_ADDR option. DSS insertion policy for bulk transfer: To reduce receiver complexity, DSS options should be inserted into all pack= ets of a bulk until the first data ACK is received for a packet contained i= n the bulk (Section 3.7). Please take the details from the corresponding sections of the document. Co= mments are welcome. Thank you. Regards, Georg Hampel --_000_154773479ED2314980CB638A48FC443484DC8B19USNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alan, all,=

 

On address availability:

I think we agree that this applies to situations where the host has knowledge from lower-layer signaling that one= of its links is down or has insufficient “link quality”. (This doe= s not necessarily mean that the IP address is down.) Presently, the host has no m= eans to inform its peer about this knowledge. If the MP_PRIO message could be equipped with an address-id, as you suggested, the host could forward this = knowledge via another path pertaining to an interface that is up and has sufficient l= ink quality. This would take 1/2RTT. It may be possible that an aggressive cross-subflow retransmission schedule would lead to similar performance. Th= is, however, is currently unknown.

 

Enforcement of path-selective operatio= n for host with simplified receiver: When the host wishes to hand over from o= ne of its interfaces (old) to another (new), the host sends two MP_PRIO option= s, where one has B=3D1 and refers to the old interface (implicitly or via addr= ess id) and the other has B=3D0 and refers to the new path (implicitly or via a= ddress id). The host MAY send both options on the same path to ensure that they ar= rive at the same time. The host MAY enclose these options onto every subsequent = packet until it receives the first packet on the new path. This allows the host to ensure fast and reliable delivery.

 

In case of conflicts, i.e. the peer do= es not like the new path, it can simply respond with its own MP_PRIO message-p= air to choose another path. To avoid ping-ponging, the unhappy peer should pick= a path that holds the host’s new interface.

 

In summary: The address-id-equipped MP_PRIO option should do the job.

 

 

On BBM:

You are bringing up a good point. Give= n the uncertainty about middle-box state on a link that has been broken, the host= is best advised to discontinue all subflows pertaining to this broken link. I sent = a question on the ML some weeks ago: In case of an imminent BBM, should a hos= t terminate all affected subflows via RST as a courtesy to clear middleboxes?=

 

Thanks,

 

Regards,

Georg

 

 

 

From: Ford, Al= an [mailto:alan.ford@roke.co.uk]
Sent: Tuesday, June 21, 2011= 12:34 PM
To: Hampel, K Georg (K Georg= ); multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierr= y)
Subject: RE: [multipathtcp] = New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks=

 

Hi Georg, all,=

 

To extract two= key points from your mail below:

 

[G.H.] The “P= ath availability” option shows up in sections 3.6 and 4.4.2. Here is an e= xample that applies to section 3.6:

 

A multi-homed mobil= e downloads a data stream from a server using 2 interfaces, say,  Wifi &= amp; 4G. Suddenly, a lower-layer signal on the mobile indicates that the 4G interface has dropped off (coverage hole or fade). The server does not know about this signal and keeps pumping data along both paths. The data sent to= the Wifi interface arrive but they cannot get delivered since all 4G-data get dropped. When RTO is exceeded for the 4G path, the server starts to realize that something is wrong and engages into retransmission, most likely on the same subflow first and after even more time, it engages into cross-subflow retransmission (dependent on local policy).

The whole mess coul= d get resolved much faster if the mobile quickly informed the server about the su= dden unavailability of its 4G interface. In this case, the server would be certa= in within 1/2 RTT that the “4G” interface is currently NOT good an= d it can immediately redirect all data including 4G-retransmissions to the “Wi= Fi” path. The mobile should NOT tear down the “4G” path since it can be b= ack up any moment. Further, MP_PRIO cannot be used since it cannot be sent on an unavailable path. Moreover, the MP_PRIO refers to individual paths, while t= he present problem applies to a specific interface, i.e. which may affect mult= iple paths.

 

Whilst I under= stand the case you are describing here, I think you may be underestimating the flexibility that could be implemented in the MPTCP retransmission algorithm.  At the moment , we do not have any significant retransmiss= ion recommendations since we have relatively little real-world experience to ba= se it on.  But an aggressive retransmission strategy would cope with this scenario quite well.  For example, if the Wifi continues well, there w= ill soon be a point where the buffer is rapidly filling at the receiver and the discrepancy between the DATA_ACK and the subflow ACK is large enough to tri= gger a retransmission on the functioning subflow. (This should probably not exce= ed max(RTT), given the receive buffer sizing).

 

[G.H.] We had an MP= TCP mailing list discussion on BBM. From this discussion I understand that BBM = on lower layer should NOT be followed on L4. The reasons given were: When a ho= st with one radio interface rapidly ping-pongs between two networks (lower-lay= er BBM at every switch), MPTCP should keep both subflows up and solely change = the activity of each path. In other words, BBM on lower layers is translated to= MBB on MPTCP. Your proposal, i.e. sending FIN on the old path, would make a switchback to the old path very slow (since you have to MP_JOIN again). Further, the remote peer may not respond to FIN if it still has data to sen= d (!). The BBM ping-pong scenario is another reason for AVAIL/UNAVAIL_ADDR.

 

In this case, = you are relying on the wireless network infrastructure retaining state (i.e. &n= bsp;NATs) for the connection while the host uses another network.  This is by no means guaranteed, and will require an adjustment to the subflow-level state machines at each host, to determine that a lost packet on an interface is n= ot cause for terminating a subflow when that same connection-level data has si= nce been successfully transmitted on another subflow (if this was applied, howe= ver, the desired result could be achieved with a MP_PRIO signal either downgradi= ng the background subflow or promoting the foreground one to be the “use= me and me alone” subflow).

 

If we were to = modify the MP_PRIO option to take an Address ID (which is something we’ve th= ought about doing before but the use cases were not clear), then you could downgr= ade one path from another. That may be sufficient (at least, with tolerant flow control).  Shortcuts of a second bit to say “Do not use” o= r “use exclusively” could also help here.  Might this cover all cases?<= o:p>

 

Regards,<= /o:p>

Alan

 

 

From: Hampel, = K Georg (K Georg) [mailto:georg.hampel@alcatel-lucent.com]
Sent: 21 June 2011 16:44
To: Ford, Alan; multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierr= y)
Subject: RE: [multipathtcp] = New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks

 

Hello Alan,

 

Thanks for reading the draft.  We= are currently implementing a low-complexity MPTCP version for path-selective mo= de (see section 4 of draft). Many of the issues in section 4 came up when we thought through the specific steps for such a design. There are multiple wa= ys to tackle these issues. I have added comments below.

 

Regards,

Georg

 

From: Ford, Al= an [mailto:alan.ford@roke.co.uk]
Sent: Tuesday, June 21, 2011= 5:50 AM
To: Hampel, K Georg (K Georg= ); multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierr= y)
Subject: RE: [multipathtcp] = New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks=

 

Hello Georg, Thierry,

 

Thanks for wri= ting this – it covers an important and interesting topic. I’ve had a= chance to read it, now, and have some comments.

 

3.3: It is definitely intentional that you can use MPTCP with no changes to send data resiliently on many paths. I’ll expand the text in the protocol draft= slightly to discuss processing the same mappings on different subflows.

 

3.4: Agreed, t= his (fluctuations in path throughput/delay) is a very valid concern and one tha= t we discuss considerably in the API draft.  It is an issue where users are best placed to drive the development of solutions.=

 

3.7: This idea= is sensible, but I would be reluctant to mandate it.  I think some text l= ike this may be sufficient: “An implementation SHOULD send DSS options th= at cover multiple segments multiple times, to reduce the need for unnecessary buffer= ing at the receiver.  It is RECOMMENDED that a sender repeats the DSS opti= on until a DATA ACK for some data covered by this mapping is received.”<= o:p>

 

“Path Av= ailability” – this is where I get confused as to what the goal of this is. Can yo= u give an example scenario where this would be useful?

Throughout the= rest of this document, I struggle to see what difference there is between path (= or interface) availability, and address availability.  We have the ADD_AD= DR and REMOVE_ADDR options to indicate the availability or loss of availabilit= y of an address (interface) on a host.  What is (UN)AVAIL_ADDR giving over = and above this? Why separate the creation of the mapping and the signalling of = the availability?

 

[G.H.] The “P= ath availability” option shows up in sections 3.6 and 4.4.2. Here is an e= xample that applies to section 3.6:

 

A multi-homed mobil= e downloads a data stream from a server using 2 interfaces, say,  Wifi &= amp; 4G. Suddenly, a lower-layer signal on the mobile indicates that the 4G interface has dropped off (coverage hole or fade). The server does not know about this signal and keeps pumping data along both paths. The data sent to= the Wifi interface arrive but they cannot get delivered since all 4G-data get dropped. When RTO is exceeded for the 4G path, the server starts to realize that something is wrong and engages into retransmission, most likely on the same subflow first and after even more time, it engages into cross-subflow retransmission (dependent on local policy).

The whole mess coul= d get resolved much faster if the mobile quickly informed the server about the su= dden unavailability of its 4G interface. In this case, the server would be certa= in within 1/2 RTT that the “4G” interface is currently NOT good an= d it can immediately redirect all data including 4G-retransmissions to the “Wi= Fi” path. The mobile should NOT tear down the “4G” path since it can be b= ack up any moment. Further, MP_PRIO cannot be used since it cannot be sent on an unavailable path. Moreover, the MP_PRIO refers to individual paths, while t= he present problem applies to a specific interface, i.e. which may affect mult= iple paths.

 

Some points on= 4.4:

 

Yes, MP_PRIO i= s not binding, although the expectation is that a host should have a good reason = for ignoring it (such as if the path appears dead to the host, or it costs too = much money) – I can’t see that we can change that.  If an end h= ost was desperate to stop receiving traffic on an interface, it could drop the subf= low.

 

If I understan= d your comment correctly, you’d like to be able to switch a single path to B= =3D0 and all the others to B=3D1 in one go, and this is the purpose of MP_SELECT?  = I guess we could adapt MP_PRIO to achieve this, by having another value that means “use me and me alone”.  Although I think I need more= convincing that it adds value!

 

[G.H] I think you summarized the essence of MP_SELECT rather well. There are multiple ways of doing this. The goal of all this is that the host can ENFORCE path-selectiv= e operation on the peer’s sender since this simplifies the host’s= receiver, AND that path-reselection can be done in the FASTEST and MOST RELIABLE possible way. Constraints are: (1) MP_PRIO with B=3D1 cannot be sent on a path that = is already down, (2) uncertainty when multiple MP_PRIO message with different B-setting arrive out of sync due to the different RTTs on the various paths= , (3) conflict resolution, i.e. host A wants receive data on path 1 but host = B wants to send data on path 2, (4) long delay in case “switching messa= ges” get lost.

 

In 4.4.2, you = talk about BBM in the scenario of a radio k= nowing that it is going to take down its interface to attach to a new network.&nbs= p; You can do this already cleanly – just FIN the old path (without a DA= TA FIN) and bring up the new one.  What is your proposal adding?

 =

[G.H.] We had an MP= TCP mailing list discussion on BBM. From this discussion I understand that BBM = on lower layer should NOT be followed on L4. The reasons given were: When a ho= st with one radio interface rapidly ping-pongs between two networks (lower-lay= er BBM at every switch), MPTCP should keep both subflows up and solely change = the activity of each path. In other words, BBM on lower layers is translated to= MBB on MPTCP. Your proposal, i.e. sending FIN on the old path, would make a switchback to the old path very slow (since you have to MP_JOIN again). Further, the remote peer may not respond to FIN if it still has data to sen= d (!). The BBM ping-pong scenario is another reason for AVAIL/UNAVAIL_ADDR.

 

 

5.1 is an interesting problem and one that Mark led some discussion of at the last IETF.  As with the discussion about AVAIL_ADDR, I don’t see the = point of JOIN_ADDR and ADD_ADDR separations, but DEFER_ADDR (or “USE_THIS_ADDR= !”) is an interesting idea that I need to think about some more!

 

[G.H.] I think Mark= had a more generic proxy solution in mind. The “transparent” proxy we= are proposing has much more stringent deployment requirements. However, there is a very important use case (put it on PDN-GW) and it can be realized through a very simple signalling enhancement (“USE_THIS_ADDR” may indeed be cl= earer).

 

Regards,<= /o:p>

Alan

 

From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Hampel, K Georg (K Georg= )
Sent: 16 June 2011 16:03
To: multipathtcp@ietf.org Cc: Klein, Thierry E (Thierr= y)
Subject: [multipathtcp] New = I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Acce= ss Networks

 

All,

 
We=
 have uploaded a new I-D.
 
Ti=
tle: Enhancements to Improve the Applicability of Multipath TCP to Wireless=
 Access Networks

 

Authors: Georg Hampel, Thierry= Klein

 

Filename: draft-hampel-mptcp-applicability-wireless-networks-00.tx=
t

 

URL: http://datatracker.ietf.org/doc/draft-hampel-mptcp-applic= ability-wireless-networks/

 

Abstract:

This document analyses the applicability of Multipath TC= P to wireless access networks with overlapping coverage area, and it discusses potential protocol extensions that aim to improve operation in such environments.  The analysis attempts to identify use cases, benefits a= s well as technical and functional obstacles encountered in the current versi= on of the protocol.  Based on this analysis, recommendations are made on feature-, signaling- and policy extensions that promise to enhance Multipath-TCP's value, versatility and market acceptance in wireless access networks.

 

 

IMPORTANT COMMENTS: Apart from a variety of recommendati= ons for research, the I-D proposes the following signaling and policy enhanceme= nts:

 

MP_SELECT option:

The host sends this option to enforce path-selective operation on its peer.  The option is generally sent on the subflow to= be used for data transmission. It may enclose an address id in case it is sent= on another subflow, e.g. in break-before-make scenarios before the designated = path becomes available. The option permits low-complexity MPTCP receiver solutio= ns (Section 4.4) as well as dynamic overhead shedding for heavily loaded serve= rs (Section 4.5).

 

AVAIL_ADDR/UNAVAIL_ADDR option(s):

The host sends this option to inform its peer about the availability/unavailability status of an interface referred to via an addre= ss id.  The enclosed address-id permits sending the option from an availa= ble interface to refer to an unavailable interface. The option permits the peer= to swiftly adjust data transmission when the host’s interface availabili= ty changes. There are multiple use cases for this option (Section 3.6, Section= 4.4 and Section 4.5).

 

DEFER_ADDR option:

The host sends this option to instruct its peer to use a specific address referred to via an address id as the destination for all future subflows. This option is required for transparent-proxy operation (section 5).

 

ADD_ADDR option:

The present version of this option should be modified: T= he option should only provide a mapping between address id and address value without further advice or request for action. When the ADD_ADDRESS option refers to the source address of the packet it is enclosed in, it can omit t= he address value. The re-interpretation of this option is necessary to support multiple instructions as provided by the options above (and the one below).=

 

JOIN_ADDR option:

The host sends this option to request subflow creation (= via MP_JOIN) to an address referred to via the enclosed address id. Currently, = the functionality of this option is melted into the ADD_ADDR option.=

 

DSS insertion policy for bulk transfer:

To reduce receiver complexity, DSS options should be inserted into all packets of a bulk until the first data ACK is received fo= r a packet contained in the bulk (Section 3.7).

 

 

Please take the details from t= he corresponding sections of the document. Comments are welcome. Thank you.

 

Regards,

Georg Hampel=

 

 

 

--_000_154773479ED2314980CB638A48FC443484DC8B19USNAVSXCHMBSA2n_-- From georg.hampel@alcatel-lucent.com Tue Jun 21 12:21:47 2011 Return-Path: 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 53F771F0C4B for ; Tue, 21 Jun 2011 12:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7irErdvRCWN for ; Tue, 21 Jun 2011 12:21:46 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id BEDCA1F0C38 for ; Tue, 21 Jun 2011 12:21:46 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p5LJLjxL022893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jun 2011 14:21:45 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5LJLi0M017736 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 Jun 2011 14:21:44 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 21 Jun 2011 14:21:44 -0500 From: "Hampel, K Georg (K Georg)" To: Joe Touch , "Ford, Alan" Date: Tue, 21 Jun 2011 14:21:42 -0500 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: AcwwMc7JGsnZgCVAQxKLDQFxDnWffAAFUqUA Message-ID: <154773479ED2314980CB638A48FC443484DC8B2A@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D15D18D@rsys005a.comm.ad.roke.co.uk> <4E00C922.6090202@isi.edu> In-Reply-To: <4E00C922.6090202@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 19:21:47 -0000 Hi Joe, all, Indeed, the AVAIL/UNAVAIL_ADDR options pursue similar intentions as propose= d by trigtran (draft-dawkins-trigtran-framework-00, dawkins-trigtran-linkup= -01). Obviously, such messages can only refer to local-link information and not t= o next-hop links. This may not be perfect but pretty good in many use cases= (as is also stated in the trigtran drafts).=20 I further think that referring to addresses rather than paths is correct in= the context of AVAIL/UNAVAIL_ADDR. If you see any inconsistencies and flaws in the present draft, please let u= s know. Thanks. Georg -----Original Message----- From: Joe Touch [mailto:touch@isi.edu]=20 Sent: Tuesday, June 21, 2011 12:39 PM To: Ford, Alan Cc: Hampel, K Georg (K Georg); multipathtcp@ietf.org; Klein, Thierry E (Thi= erry) Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Interesting draft, but this - like the original work - continues to=20 confuse IP addresses with paths. I raised this point many times during the original multipath discussion,=20 but it continues to be lost at each successive addition to the work -=20 partly because the work continues to me misnamed "multipathTCP", vs.=20 multiaddressTCP *When* (not if) wireless links are one hop upstream of a device (e.g.,=20 in 3G/4G WiFi hotspot boxes), information about an IP address tells you=20 nothing about the availability of the **path**. It'd be useful for this group, esp. those discussing this doc, to=20 consider previous IETF BoF attempts in this area, e.g., trigtran from=20 summer 2003 (unfortunately RFC5184 apparently didn't, since it doesn't=20 address the above limitations unfortunately). Joe From touch@isi.edu Tue Jun 21 13:12:42 2011 Return-Path: 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 7A12F11E80DA for ; Tue, 21 Jun 2011 13:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAPbeinXfDB4 for ; Tue, 21 Jun 2011 13:12:41 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2C64D11E807A for ; Tue, 21 Jun 2011 13:12:41 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p5LKBsxF011383 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 21 Jun 2011 13:11:54 -0700 (PDT) Message-ID: <4E00FB0A.7060408@isi.edu> Date: Tue, 21 Jun 2011 13:11:54 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Hampel, K Georg (K Georg)" References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D15D18D@rsys005a.comm.ad.roke.co.uk> <4E00C922.6090202@isi.edu> <154773479ED2314980CB638A48FC443484DC8B2A@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC443484DC8B2A@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 20:12:42 -0000 On 6/21/2011 12:21 PM, Hampel, K Georg (K Georg) wrote: > Hi Joe, all, > > Indeed, the AVAIL/UNAVAIL_ADDR options pursue similar intentions as proposed by trigtran (draft-dawkins-trigtran-framework-00, dawkins-trigtran-linkup-01). > Obviously, such messages can only refer to local-link information and not to next-hop links. This may not be perfect but pretty good in many use cases (as is also stated in the trigtran drafts). > > I further think that referring to addresses rather than paths is correct in the context of AVAIL/UNAVAIL_ADDR. > > If you see any inconsistencies and flaws in the present draft, please let us know. Thanks. FWUW, I think the key would be to focus on the fact that these are addresses, and include a brief discussion on the limitations of the approach - i.e., it works for only directly attached interfaces. Joe > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, June 21, 2011 12:39 PM > To: Ford, Alan > Cc: Hampel, K Georg (K Georg); multipathtcp@ietf.org; Klein, Thierry E (Thierry) > Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks > > Interesting draft, but this - like the original work - continues to > confuse IP addresses with paths. > > I raised this point many times during the original multipath discussion, > but it continues to be lost at each successive addition to the work - > partly because the work continues to me misnamed "multipathTCP", vs. > multiaddressTCP > > *When* (not if) wireless links are one hop upstream of a device (e.g., > in 3G/4G WiFi hotspot boxes), information about an IP address tells you > nothing about the availability of the **path**. > > It'd be useful for this group, esp. those discussing this doc, to > consider previous IETF BoF attempts in this area, e.g., trigtran from > summer 2003 (unfortunately RFC5184 apparently didn't, since it doesn't > address the above limitations unfortunately). > > Joe From georg.hampel@alcatel-lucent.com Wed Jun 22 07:31:18 2011 Return-Path: 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 1296D21F84FA for ; Wed, 22 Jun 2011 07:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEZ-qY3+4rt0 for ; Wed, 22 Jun 2011 07:31:17 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id D150821F84F9 for ; Wed, 22 Jun 2011 07:31:16 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p5MEVFs5003885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Jun 2011 09:31:15 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5MEVDg3031348 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 22 Jun 2011 09:31:13 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 22 Jun 2011 09:31:13 -0500 From: "Hampel, K Georg (K Georg)" To: "christoph.paasch@uclouvain.be" , "multipathtcp@ietf.org" Date: Wed, 22 Jun 2011 09:31:12 -0500 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: AcwwBFlmwpW3XaGERMilI3uMy6//swA3RM8Q Message-ID: <154773479ED2314980CB638A48FC443484DC8D6F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D15D18D@rsys005a.comm.ad.roke.co.uk> <201106211314.04612.christoph.paasch@uclouvain.be> In-Reply-To: <201106211314.04612.christoph.paasch@uclouvain.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 14:31:18 -0000 Hi Christoph, all, I missed Christoph's comments on Alan's comments in my last reply on Christ= oph's comments. There is a lot of discussion material.=20 I have inserted my comments to Christoph's comments below (marked with [GH]= ). Thanks. Regards, Georg -----Original Message----- From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be]=20 Sent: Tuesday, June 21, 2011 7:14 AM To: multipathtcp@ietf.org Cc: Ford, Alan; Hampel, K Georg (K Georg); Klein, Thierry E (Thierry) Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi all, I took also some time to read the draft and have some comments on your draf= t=20 and on Alan's comments. 3.6: "The ADD_ADDR option can be simplified when it refers to the packet's sourc= e=20 address." I don't see a case where the ADD_ADDR-option is sent, refering to the packe= t's=20 source address, because the address-id of this source-address has already b= een=20 provided by the MP_JOIN when establishing the subflow. On Tuesday 21 June 2011 wrote Ford, Alan: > 3.7: This idea is sensible, but I would be reluctant to mandate it. I > think some text like this may be sufficient: "An implementation SHOULD > send DSS options that cover multiple segments multiple times, to reduce > the need for unnecessary buffering at the receiver. It is RECOMMENDED > that a sender repeats the DSS option until a DATA ACK for some data > covered by this mapping is received." In fact, if the first packet (carrying the DSS) is lost, packets will be=20 stored in the subflow-specific out-of-order queue, because we have a loss a= t=20 the subflow-level. [GH] Our intention is to avoid this out-of-order queue if possible. In any case, as long as the whole mapping of the payload has not been=20 received, we need to buffer the packets for the checksum-verification. [GH] I was under the impression that the checksum applies to the packet onl= y. In my opinion this would make things much simpler. Is there a specific r= eason to apply the checksum to the entire bulk rather than solely the packe= t? Things would get much simpler if the checksum were packet-specific. 4.3: "In case the old subflow becomes unavailable, retransmissions can..." Maybe you should note, that the retransmissions have to be done on the new= =20 subflow before the regular data-stream. Otherwise you might have problems, = in=20 the next paragraph. [GH] One can support 2 distinct scenarios: In one, no cross-subflow retrans= missions occur since the old subflow is still in good shape. In the other, = all unacknowledged data on the old subflow are assumed lost and retransmitt= ed on the new subflow in one bulk. This would make things substantially sim= pler. Concerning your removal of the DSS-options. Is it intended that after remov= ing=20 the DSS-options the host is still able to switch to another subflow? If this is the case, then we have problems with middleboxes modifying the=20 content of packets (e.g., IP-address rewriting). If they add/remove a byte,= =20 the data-sequence mapping between the two hosts isn't the same anymore. [GH] Yes, we want to keep switching. We were thinking of using an infinite = mapping between re-selection events. In other words: The hosts operate in a= "fall-back mode" in between re-selection events. I have copied/pasted the = corresponding text from draft-ietf-mptcp-multiaddressed-03: [draft-ietf-mptcp-multiaddressed-03.txt: section 3.3.1] ...An "infinite" mapping can be used to fallback to regular TCP by mapping the subflow-level data to the connection-level data for the remainder of the connection (see Section 3.5). This is achieved by setting the data-level length field to the reserved value of 0. ... [draft-ietf-mptcp-multiaddressed-03.txt: section 3.5] ... This connection will then continue to appear as a regular TCP session, and a middlebox may change the payload without causing unintentional harm.... ...When a connection is in fallback mode, only one subflow can send data at a time. Otherwise, the receiver would not know how to reorder the data. However, subflows can be opened and closed as necessary, as long as a single one is active at any point. [GH] Quite honestly, we haven't really considered payload-rewriting middleb= oxes. I don't know how frequent they are and I don't know how well applicat= ions work with them. I further don't understand how the "TCP-fallback-with-= consecutive-subflow-switch" proposed in the above draft-ietf-mptcp-multiadd= ressed-03 reference addresses this issue. I could imagine a solution, where= the host "exits" TCP-fallback mode (i.e. re-enters MPTCP mode) by insertin= g a re-normalizing DSS, i.e. a new mapping based on the existing SN (rather= than vice versa). This would work as long as payload-rewriting does not ha= ppen during the re-selection event. 4.3: "Using only one flow/congestion engine significantly..." So, the intention is to have the same congestion-window and slow-start- threshhold on the new subflow as on the old-one, and thus you do not slow- start on the new subflow? I'm not sure if this is a good idea. You will probably overload the network= in=20 the beginning. It may also be, that statefull firewalls are dropping packet= s,=20 because they do not fit in the expected window. [GH] We have done tests on this. The new path may receive a brief burst whi= ch the network may not be able to handle. This burst takes at most RTO. The= n the host goes into slow start. Note that 3GPP's WLAN-interoperability sol= utions provide the same functionality with one flow engine. The same applie= s to the Mobile IP family. In turn, I would like to see real measurements on how much better the full-= fledge MPTCP host performs in this case. Don't worry about firewalls: The simplified host has to ensure each subflow= 's integrity, i.e. that all SNs fit in expected window etc. > "Path Availability" - this is where I get confused as to what the goal > of this is. Can you give an example scenario where this would be useful? >=20 > Throughout the rest of this document, I struggle to see what difference > there is between path (or interface) availability, and address > availability. We have the ADD_ADDR and REMOVE_ADDR options to indicate > the availability or loss of availability of an address (interface) on a > host. What is (UN)AVAIL_ADDR giving over and above this? Why separate > the creation of the mapping and the signalling of the availability? Agree with Alan on this point. I don't really see the difference between=20 ADD/REMOVE and AVAIL/UNAVAIL. [GH] ADD/REMOVE_ADDR create/delete subflows. AVAIL/UNAVAIL_ADDR indicate th= roughput conditions of addresses pertaining to existing subflows. No subflo= w-teardown/setup necessary. However, the remote host may quickly adapt the = subflow subset it uses for data transmission. 4.4.2: "Obviously, the host most have announced the mapping between address id and= =20 address value prior to the handover using the ADD_ADDRESS option." Here, we are in the BBM-scenario. Thus, we do not yet have the new address.= So=20 we cannot announce it with ADD_ADDR, because we don't know which address we= =20 will get. [GH] The BBM situation needs more discussion: Does lower-layer BBM imply su= bflow BBM? If not, it is possible that moving back to an old network provid= es you with the same IP address. Cheers, Christoph -- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp Universit=E9 Catholique de Louvain www.rollerbulls.be -- From christoph.paasch@uclouvain.be Wed Jun 22 08:17:06 2011 Return-Path: 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 3A6C311E80D8 for ; Wed, 22 Jun 2011 08:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc7mqF9xxAMI for ; Wed, 22 Jun 2011 08:17:05 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id F138311E80D7 for ; Wed, 22 Jun 2011 08:17:04 -0700 (PDT) Received: from cpaasch-mac.localnet (unknown [172.17.0.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 68D1B1C54A5; Wed, 22 Jun 2011 17:15:48 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 68D1B1C54A5 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1308755748; bh=71gI8prZATNOPFSgJGCAX1mwaraVjaEiFhrgi+sGniA=; h=From:Reply-To:To:Subject:Date:Cc:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id; b=S5I4sg5pPCfMdbKqxO6TkiPsOF9sxf/Gvrur7LjphfJG5jlgCPbAIOKvVfsnbqOjs +ca630eqzutEspP1gntwR2rX2bTqKNzy4y/TGWpb6PKk0Ln/ZBJP46lshdvPuM38t+ wbQWBC8eQzmN8aIGgw15Qkvs8LzUNLaH93u0IJZw= From: Christoph Paasch Organization: =?iso-8859-1?q?Universit=E9_Catholique_de?= Louvain To: "Hampel, K Georg (K Georg)" Date: Wed, 22 Jun 2011 17:15:47 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic; KDE/4.6.2; x86_64; ; ) References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <201106211314.04612.christoph.paasch@uclouvain.be> <154773479ED2314980CB638A48FC443484DC8D6F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC443484DC8D6F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201106221715.47945.christoph.paasch@uclouvain.be> X-Virus-Scanned: clamav-milter 0.97-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 68D1B1C54A5.A1D23 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] =?iso-8859-1?q?New_I-D=3A_Enhancements_to_Improve_?= =?iso-8859-1?q?the=09Applicability_of_Multipath_TCP_to_Wireless_Access_Ne?= =?iso-8859-1?q?tworks?= X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:17:06 -0000 Hi Georg, thanks for your reply. In another mail you said, that you are implementing the path-selective vers= ion=20 of MPTCP. Do you implement it on top of our Linux Kernel implementation of= =20 MPTCP? Is the source-code available in a public git? Some comments inline. On Wednesday 22 June 2011 wrote Hampel, K Georg (K Georg): > On Tuesday 21 June 2011 wrote Ford, Alan: > > 3.7: This idea is sensible, but I would be reluctant to mandate it. I > > think some text like this may be sufficient: "An implementation SHOULD > > send DSS options that cover multiple segments multiple times, to reduce > > the need for unnecessary buffering at the receiver. It is RECOMMENDED > > that a sender repeats the DSS option until a DATA ACK for some data > > covered by this mapping is received." >=20 > In fact, if the first packet (carrying the DSS) is lost, packets will be > stored in the subflow-specific out-of-order queue, because we have a loss > at the subflow-level. >=20 > [GH] Our intention is to avoid this out-of-order queue if possible. =46rom an implementation point-of-view, I don't really see how to avoid thi= s=20 out-of-order queue. We still need to be sure that the TCP subflow behaves a= s =20 regular TCP. Thus, if some packets of a bulk of packets get lost, we need t= o=20 store the out-of-order packets (I mean out-of-order at a subflow-level) in = a=20 subflow out-of-order queue to be sure that the ack's we will send back to t= he=20 sender are correct (e.g., holes in the out-of-order queue need to be filled= up=20 correctly). Of course, if these out-of-order packets cover already a full DSS-mapping, = we=20 may optimize the implementation so that it already pushes the payload to th= e=20 data-level. But still, the packet needs to stay in the subflow out-of-order- queue. > In any case, as long as the whole mapping of the payload has not been > received, we need to buffer the packets for the checksum-verification. >=20 > [GH] I was under the impression that the checksum applies to the packet > only. In my opinion this would make things much simpler. Is there a > specific reason to apply the checksum to the entire bulk rather than > solely the packet? Things would get much simpler if the checksum were > packet-specific. If the DSS-mapping covers multiple packets, the checksum in the DSS-option = is=20 on the whole payload of these packets plus the pseudo-header. > Concerning your removal of the DSS-options. Is it intended that after > removing the DSS-options the host is still able to switch to another > subflow? If this is the case, then we have problems with middleboxes > modifying the content of packets (e.g., IP-address rewriting). If they > add/remove a byte, the data-sequence mapping between the two hosts isn't > the same anymore. >=20 > [GH] Yes, we want to keep switching. We were thinking of using an infinite > mapping between re-selection events. In other words: The hosts operate in > a "fall-back mode" in between re-selection events. I have copied/pasted > the corresponding text from draft-ietf-mptcp-multiaddressed-03: Ok, assuming there are no content-changing middleboxes, you can indead skip= =20 from sending DSS's by doing like in the draft-ietf-mptcp-multiaddressed-03.= =20 But you then do not need to wait for the DATA_ACK's as described in your=20 draft, as the infinite mapping is "announced" with data_len =3D=3D 0. > [GH] Quite honestly, we haven't really considered payload-rewriting > middleboxes. I don't know how frequent they are and I don't know how well > applications work with them. I further don't understand how the > "TCP-fallback-with-consecutive-subflow-switch" proposed in the above > draft-ietf-mptcp-multiaddressed-03 reference addresses this issue. I could > imagine a solution, where the host "exits" TCP-fallback mode (i.e. > re-enters MPTCP mode) by inserting a re-normalizing DSS, i.e. a new > mapping based on the existing SN (rather than vice versa). This would work > as long as payload-rewriting does not happen during the re-selection > event. True, I'm also asking myself how "TCP-fallback-with-consecutive-subflow- switch" of draft-ietf-mptcp-multiaddressed-03 can work. The re-normalizing DSS should be ok without these middleboxes. Christoph =2D- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp Universit=E9 Catholique de Louvain www.rollerbulls.be =2D- From georg.hampel@alcatel-lucent.com Wed Jun 22 10:25:35 2011 Return-Path: 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 9CE5321F845F for ; Wed, 22 Jun 2011 10:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46IHvEWt1UiY for ; Wed, 22 Jun 2011 10:25:34 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8898821F845B for ; Wed, 22 Jun 2011 10:25:31 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p5MHPTl8009078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Jun 2011 12:25:29 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5MHPSkO013870 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 22 Jun 2011 12:25:28 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 22 Jun 2011 12:25:28 -0500 From: "Hampel, K Georg (K Georg)" To: "christoph.paasch@uclouvain.be" Date: Wed, 22 Jun 2011 12:25:27 -0500 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: Acww70gLTCBMWFVoRFWnnUTUT+53cgADIlYg Message-ID: <154773479ED2314980CB638A48FC443484DC8E59@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <201106211314.04612.christoph.paasch@uclouvain.be> <154773479ED2314980CB638A48FC443484DC8D6F@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <201106221715.47945.christoph.paasch@uclouvain.be> In-Reply-To: <201106221715.47945.christoph.paasch@uclouvain.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 17:25:35 -0000 Hi Christoph, It is a fresh implementation. We are trying to put the first version on net= filter_queue which allows doing packet processing in userspace. (Operation = w/o out-of-order queue is very important in this case.) The source code will be available when done. By then, we would also like to= test interoperability with other MPTCP implementations. Comments inline. Thanks. Regards, Georg=20 -----Original Message----- From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be]=20 Sent: Wednesday, June 22, 2011 11:16 AM To: Hampel, K Georg (K Georg) Cc: multipathtcp@ietf.org; Ford, Alan; Klein, Thierry E (Thierry) Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi Georg, thanks for your reply. In another mail you said, that you are implementing the path-selective vers= ion=20 of MPTCP. Do you implement it on top of our Linux Kernel implementation of= =20 MPTCP? Is the source-code available in a public git? Some comments inline. On Wednesday 22 June 2011 wrote Hampel, K Georg (K Georg): > On Tuesday 21 June 2011 wrote Ford, Alan: > > 3.7: This idea is sensible, but I would be reluctant to mandate it. I > > think some text like this may be sufficient: "An implementation SHOULD > > send DSS options that cover multiple segments multiple times, to reduce > > the need for unnecessary buffering at the receiver. It is RECOMMENDED > > that a sender repeats the DSS option until a DATA ACK for some data > > covered by this mapping is received." >=20 > In fact, if the first packet (carrying the DSS) is lost, packets will be > stored in the subflow-specific out-of-order queue, because we have a loss > at the subflow-level. >=20 > [GH] Our intention is to avoid this out-of-order queue if possible. >From an implementation point-of-view, I don't really see how to avoid this= =20 out-of-order queue. We still need to be sure that the TCP subflow behaves a= s =20 regular TCP. Thus, if some packets of a bulk of packets get lost, we need t= o=20 store the out-of-order packets (I mean out-of-order at a subflow-level) in = a=20 subflow out-of-order queue to be sure that the ack's we will send back to t= he=20 sender are correct (e.g., holes in the out-of-order queue need to be filled= up=20 correctly). Of course, if these out-of-order packets cover already a full DSS-mapping, = we=20 may optimize the implementation so that it already pushes the payload to th= e=20 data-level. But still, the packet needs to stay in the subflow out-of-order= - queue. [GH2] Here's the idea: bulk-size is either infinity or packet size. If infi= nity, the mapping is always the same until explicitly changed through a new= DSS. The new mapping (i.e. DSS) must be inserted on all consecutive packet= s until the sender receives the first data ACK confirming the latest mappin= g change (this motivates section 3.7. in our draft). If bulk =3D packet siz= e, things are straightforward since they only apply to the present packet. = The consecutive packets are expected to carry a DSS until end-to-end synch = is achieved again. > In any case, as long as the whole mapping of the payload has not been > received, we need to buffer the packets for the checksum-verification. >=20 > [GH] I was under the impression that the checksum applies to the packet > only. In my opinion this would make things much simpler. Is there a > specific reason to apply the checksum to the entire bulk rather than > solely the packet? Things would get much simpler if the checksum were > packet-specific. If the DSS-mapping covers multiple packets, the checksum in the DSS-option = is=20 on the whole payload of these packets plus the pseudo-header. [GH2] And why not simply put one DSS in each packet of the bulk? Then the c= hecksum only has to cover the packet and all out-of-order queuing is elimin= ated! (Am I missing something here?) > Concerning your removal of the DSS-options. Is it intended that after > removing the DSS-options the host is still able to switch to another > subflow? If this is the case, then we have problems with middleboxes > modifying the content of packets (e.g., IP-address rewriting). If they > add/remove a byte, the data-sequence mapping between the two hosts isn't > the same anymore. >=20 > [GH] Yes, we want to keep switching. We were thinking of using an infinit= e > mapping between re-selection events. In other words: The hosts operate in > a "fall-back mode" in between re-selection events. I have copied/pasted > the corresponding text from draft-ietf-mptcp-multiaddressed-03: Ok, assuming there are no content-changing middleboxes, you can indead skip= =20 from sending DSS's by doing like in the draft-ietf-mptcp-multiaddressed-03.= =20 But you then do not need to wait for the DATA_ACK's as described in your=20 draft, as the infinite mapping is "announced" with data_len =3D=3D 0. [GH2] That's the plan. The advantage is that path-selective MPTCP becomes c= onventional TCP in between re-selection events. > [GH] Quite honestly, we haven't really considered payload-rewriting > middleboxes. I don't know how frequent they are and I don't know how well > applications work with them. I further don't understand how the > "TCP-fallback-with-consecutive-subflow-switch" proposed in the above > draft-ietf-mptcp-multiaddressed-03 reference addresses this issue. I coul= d > imagine a solution, where the host "exits" TCP-fallback mode (i.e. > re-enters MPTCP mode) by inserting a re-normalizing DSS, i.e. a new > mapping based on the existing SN (rather than vice versa). This would wor= k > as long as payload-rewriting does not happen during the re-selection > event. True, I'm also asking myself how "TCP-fallback-with-consecutive-subflow- switch" of draft-ietf-mptcp-multiaddressed-03 can work. The re-normalizing DSS should be ok without these middleboxes. [GH2] The re-normalizing DSS should actually work WITH these payload-changi= ng middleboxes. Example: Mapping on active subflow 1, established via a DSS:=20 Sender: DSN =3D 1000, SN1 =3D 100, Receiver: SN1' =3D 100 =3D> DSN =3D 100= 0=20 200 bytes later, middlebox adds 8 bytes. The mapping would be: Sender: DSN =3D 1200, SN1 =3D 300, Receiver: SN1' =3D 308 =3D> DSN =3D 120= 8. The hosts do not notice the mismatch since DSSs are not sent. At DSN =3D 1400, the sender re-normalizes the mapping by sending a DSS: Sender: DSN 1400, SN1 =3D 400, Receiver: SN1'=3D 408 =3D> DSN =3D 1400 The receiver may notice that it somehow received a few bytes more but it do= es not care. In fact, it does not even need to keep the notion of a DSN bet= ween DSS transmissions. Christoph -- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp Universit=E9 Catholique de Louvain www.rollerbulls.be -- From christoph.paasch@uclouvain.be Fri Jun 24 03:02:15 2011 Return-Path: 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 6F2FC21F8455 for ; Fri, 24 Jun 2011 03:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tG-SnyCA37gQ for ; Fri, 24 Jun 2011 03:02:14 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0440F21F8453 for ; Fri, 24 Jun 2011 03:02:13 -0700 (PDT) Received: from cpaasch-mac.localnet (unknown [172.17.0.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 5766A11E12C; Fri, 24 Jun 2011 12:02:08 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 5766A11E12C DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1308909728; bh=VC6fFcrzC/rLcAcva3TA73h9XccUh6151K956ekSM7E=; h=From:Reply-To:To:Subject:Date:Cc:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id; b=gMUDFQakUbejKtycC36UOm6+4SOq2AENkyyIWJwHdlbpZYj3Vf0EfpadBkgU813Nk FUN7DYpxBnGUF7wcXRlxK1uZF1Kf62hc3RgjgqZxevkKNU0JPBSwo8o2UywVXMnOpy ZuLNdtZdOakAgkg1vAcQO5IKrBaDU46hJEWnQJd4= From: Christoph Paasch Organization: =?iso-8859-1?q?Universit=E9_Catholique_de?= Louvain To: "Hampel, K Georg (K Georg)" Date: Fri, 24 Jun 2011 12:02:07 +0200 User-Agent: KMail/1.13.6 (Linux/2.6.38-10-generic; KDE/4.6.2; x86_64; ; ) References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <201106221715.47945.christoph.paasch@uclouvain.be> <154773479ED2314980CB638A48FC443484DC8E59@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC443484DC8E59@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201106241202.08056.christoph.paasch@uclouvain.be> X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 5766A11E12C.A1A31 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] =?iso-8859-1?q?New_I-D=3A_Enhancements_to_Improve_?= =?iso-8859-1?q?the=09Applicability_of_Multipath_TCP_to_Wireless_Access_Ne?= =?iso-8859-1?q?tworks?= X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 10:02:15 -0000 Hi, On Wednesday 22 June 2011 wrote Hampel, K Georg (K Georg): > The source code will be available when done. By then, we would also like = to > test interoperability with other MPTCP implementations. You can get our kernel-implementation from http://inl.info.ucl.ac.be/mptcp/= if=20 you want to test interoperability. (however we do not yet support the hmac- based security-mechanism) I'm looking forward to have a look at your code. Comments inline. > [GH2] Here's the idea: bulk-size is either infinity or packet size. If > infinity, the mapping is always the same until explicitly changed through > a new DSS. The new mapping (i.e. DSS) must be inserted on all consecutive > packets until the sender receives the first data ACK confirming the latest > mapping change (this motivates section 3.7. in our draft). If bulk =3D > packet size, things are straightforward since they only apply to the > present packet. The consecutive packets are expected to carry a DSS until > end-to-end synch is achieved again. > If the DSS-mapping covers multiple packets, the checksum in the DSS-option > is on the whole payload of these packets plus the pseudo-header. >=20 > [GH2] And why not simply put one DSS in each packet of the bulk? Then the > checksum only has to cover the packet and all out-of-order queuing is > eliminated! (Am I missing something here?) Yes, if the DSS-mapping is per-packet you do not need to buffer the packets= =20 for DSS-checksum verification. However, concerning the subflow-out-of-order queue. Consider the following= =20 packet-sequence arriving with subflow-sequence-numbers: 9 - 8 - 6 - 5 - 3 - 2 Packets 1, 4 and 7 are lost. We need to store all the packets in the subflow ofo-queue. Duplicate acks=20 trigger a fast-retransmit and packet 1 will be retransmitted. At reception of packet 1, we can push 1, 2 and 3 to the data-receive-queue = and=20 thus these packets are available to the application. The subflow-acks will= =20 have sequence-number 4. Again, the dup-acks will trigger a fast-retransmit = of=20 packet 4 (assuming SACK is disabled). And so on... How can you handle the gaps in the subflow-sequence space and send correct= =20 subflow-acks without a subflow ofo-queue? (even if the DSS-mapping covers o= nly=20 single packets) > True, I'm also asking myself how "TCP-fallback-with-consecutive-subflow- > switch" of draft-ietf-mptcp-multiaddressed-03 can work. > The re-normalizing DSS should be ok without these middleboxes. >=20 > [GH2] The re-normalizing DSS should actually work WITH these > payload-changing middleboxes. Example: Mapping on active subflow 1, > established via a DSS: > Sender: DSN =3D 1000, SN1 =3D 100, Receiver: SN1' =3D 100 =3D> DSN =3D 1= 000 > 200 bytes later, middlebox adds 8 bytes. The mapping would be: > Sender: DSN =3D 1200, SN1 =3D 300, Receiver: SN1' =3D 308 =3D> DSN =3D 1= 208. > The hosts do not notice the mismatch since DSSs are not sent. > At DSN =3D 1400, the sender re-normalizes the mapping by sending a DSS: > Sender: DSN 1400, SN1 =3D 400, Receiver: SN1'=3D 408 =3D> DSN =3D 1400 > The receiver may notice that it somehow received a few bytes more but it > does not care. In fact, it does not even need to keep the notion of a DSN > between DSS transmissions. Yes, that should be ok. The DSS should maybe be marked as "re-normalizer" t= o=20 make the renormalisation explicit. The old subflow however needs to be correctly closed with a FIN, because=20 otherwise both hosts may be unsure about where they are in the sequence-spa= ce. Imagine, if the old subflow breaks, and the sender received the subflow-ack= s=20 until 300 but the receiver got subflow-data until 408. Then, sending the re-normalizing DSS on the new-subflow will result in a=20 corrupted data-stream at the receiver, because he will append the=20 retransmitted data which goes from 1300 to 1400 (of the old subflow - becau= se=20 only subflow-ack 300 has been received by the sender) to the received 1408. Maybe, re-normalisation can be achieved by changing the subflow-sequence=20 number inside the re-normalizing DSS-option to be the one of the old subflo= w? But this change of the DSS-option and may be not a so good idea. We will ha= ve=20 problems, if this renormalizing DSS-packet get's split by a middlebox or TS= O.=20 As the subflow-sequence number in the DSS-option is the one of the old=20 subflow, we will overwrite the data-stream. Christoph =2D- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp Universit=E9 Catholique de Louvain www.rollerbulls.be =2D- From georg.hampel@alcatel-lucent.com Fri Jun 24 07:15:12 2011 Return-Path: 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 1374B21F84EC for ; Fri, 24 Jun 2011 07:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_32=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nW2vpFu7RU8x for ; Fri, 24 Jun 2011 07:15:10 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id A923221F84E3 for ; Fri, 24 Jun 2011 07:15:10 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p5OEF9HG008208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Jun 2011 09:15:09 -0500 (CDT) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5OEF8Rb000417 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 24 Jun 2011 09:15:08 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 24 Jun 2011 09:15:08 -0500 From: "Hampel, K Georg (K Georg)" To: "christoph.paasch@uclouvain.be" Date: Fri, 24 Jun 2011 09:15:07 -0500 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: AcwyVcw5aAF5CMHFRUSrJyigRY3SxAAG6ePQ Message-ID: <154773479ED2314980CB638A48FC443484E4A6CF@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <201106221715.47945.christoph.paasch@uclouvain.be> <154773479ED2314980CB638A48FC443484DC8E59@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <201106241202.08056.christoph.paasch@uclouvain.be> In-Reply-To: <201106241202.08056.christoph.paasch@uclouvain.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 14:15:12 -0000 Hi Cristoph, all, Thanks for the link to the MPTCP code. We're skipping HMACs as well. Further comments inserted below. Regards, Georg -----Original Message----- From: Christoph Paasch [mailto:christoph.paasch@uclouvain.be]=20 Sent: Friday, June 24, 2011 6:02 AM To: Hampel, K Georg (K Georg) Cc: multipathtcp@ietf.org; Ford, Alan; Klein, Thierry E (Thierry) Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi, On Wednesday 22 June 2011 wrote Hampel, K Georg (K Georg): > The source code will be available when done. By then, we would also like = to > test interoperability with other MPTCP implementations. You can get our kernel-implementation from http://inl.info.ucl.ac.be/mptcp/= if=20 you want to test interoperability. (however we do not yet support the hmac- based security-mechanism) I'm looking forward to have a look at your code. [GH3] We also look forward to having a look at our (finished) code...=20 Comments inline. > [GH2] Here's the idea: bulk-size is either infinity or packet size. If > infinity, the mapping is always the same until explicitly changed through > a new DSS. The new mapping (i.e. DSS) must be inserted on all consecutive > packets until the sender receives the first data ACK confirming the lates= t > mapping change (this motivates section 3.7. in our draft). If bulk =3D > packet size, things are straightforward since they only apply to the > present packet. The consecutive packets are expected to carry a DSS until > end-to-end synch is achieved again. > If the DSS-mapping covers multiple packets, the checksum in the DSS-optio= n > is on the whole payload of these packets plus the pseudo-header. >=20 > [GH2] And why not simply put one DSS in each packet of the bulk? Then the > checksum only has to cover the packet and all out-of-order queuing is > eliminated! (Am I missing something here?) Yes, if the DSS-mapping is per-packet you do not need to buffer the packets= =20 for DSS-checksum verification. However, concerning the subflow-out-of-order queue. Consider the following= =20 packet-sequence arriving with subflow-sequence-numbers: 9 - 8 - 6 - 5 - 3 - 2 Packets 1, 4 and 7 are lost. We need to store all the packets in the subflow ofo-queue. Duplicate acks=20 trigger a fast-retransmit and packet 1 will be retransmitted. At reception of packet 1, we can push 1, 2 and 3 to the data-receive-queue = and=20 thus these packets are available to the application. The subflow-acks will= =20 have sequence-number 4. Again, the dup-acks will trigger a fast-retransmit = of=20 packet 4 (assuming SACK is disabled). And so on... How can you handle the gaps in the subflow-sequence space and send correct= =20 subflow-acks without a subflow ofo-queue? (even if the DSS-mapping covers o= nly=20 single packets) [GH3] We use one TCP control block which has an ofo queue and handles all r= eordering and retransmissions, etc. Since it operates in the DSN space, we = only have to swap out DSN<=3D>SN and vv underneath. This can be done sequen= tially (i.e. packet by packet) as long as we have the corresponding mapping= . The only thing we have to cache is this mapping information. Without cros= s-flow retransmissions that's only one integer. With cross-flow retransmiss= ion it can become a little longer.=20 > True, I'm also asking myself how "TCP-fallback-with-consecutive-subflow- > switch" of draft-ietf-mptcp-multiaddressed-03 can work. > The re-normalizing DSS should be ok without these middleboxes. >=20 > [GH2] The re-normalizing DSS should actually work WITH these > payload-changing middleboxes. Example: Mapping on active subflow 1, > established via a DSS: > Sender: DSN =3D 1000, SN1 =3D 100, Receiver: SN1' =3D 100 =3D> DSN =3D 1= 000 > 200 bytes later, middlebox adds 8 bytes. The mapping would be: > Sender: DSN =3D 1200, SN1 =3D 300, Receiver: SN1' =3D 308 =3D> DSN =3D 1= 208. > The hosts do not notice the mismatch since DSSs are not sent. > At DSN =3D 1400, the sender re-normalizes the mapping by sending a DSS: > Sender: DSN 1400, SN1 =3D 400, Receiver: SN1'=3D 408 =3D> DSN =3D 1400 > The receiver may notice that it somehow received a few bytes more but it > does not care. In fact, it does not even need to keep the notion of a DSN > between DSS transmissions. Yes, that should be ok. The DSS should maybe be marked as "re-normalizer" t= o=20 make the renormalisation explicit. The old subflow however needs to be correctly closed with a FIN, because=20 otherwise both hosts may be unsure about where they are in the sequence-spa= ce. Imagine, if the old subflow breaks, and the sender received the subflow-ack= s=20 until 300 but the receiver got subflow-data until 408. Then, sending the re-normalizing DSS on the new-subflow will result in a=20 corrupted data-stream at the receiver, because he will append the=20 retransmitted data which goes from 1300 to 1400 (of the old subflow - becau= se=20 only subflow-ack 300 has been received by the sender) to the received 1408. Maybe, re-normalisation can be achieved by changing the subflow-sequence=20 number inside the re-normalizing DSS-option to be the one of the old subflo= w? But this change of the DSS-option and may be not a so good idea. We will ha= ve=20 problems, if this renormalizing DSS-packet get's split by a middlebox or TS= O.=20 As the subflow-sequence number in the DSS-option is the one of the old=20 subflow, we will overwrite the data-stream. [GH3] The whole payload-adding-middlebox is a mess. Any solution you propos= e only works if the middlebox behaves "well" (i.e. does not add packets) du= ring subflow switching or mapping re-normalization. Buy the way: I thought that the mapping re-normalizer is sent on the old su= bflow just before switching. This creates a trustworthy global DSN which ca= n be used to synchronize both subflows during switching. After switching, t= he mapping can be "forgotten" until the next switching event approaches. Yo= u don't have to close the old subflow. You're right in that this approach o= nly works in clean MBB scenarios. It fails if the old subflow breaks before= you have sent the re-normalizer. Christoph -- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp Universit=E9 Catholique de Louvain www.rollerbulls.be -- From yoshifumi.nishida@gmail.com Mon Jun 27 02:15:53 2011 Return-Path: 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 0D5B021F85D1 for ; Mon, 27 Jun 2011 02:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mOzWPuUBfE7 for ; Mon, 27 Jun 2011 02:15:52 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F21221F85C5 for ; Mon, 27 Jun 2011 02:15:49 -0700 (PDT) Received: by iye7 with SMTP id 7so5714474iye.31 for ; Mon, 27 Jun 2011 02:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=VlCAGfD/pjK0nWcSUDef6qKTpQheWXZ0UQHFyqH3MZk=; b=dOxNtQVgbMqiXwj6gxxn9zsnfcFWamthjoKQls3lIGn28eJlG+oUp5csctPeTs31KY iUVd6kfiBQE8MOv2loFEerv4xG6WFQd3mXPjLvTHYXzuaU9qDglomOBTDgOockeMe02k An2ljhxp9/NyrDh3N12TPlfCgXXxbav2mUsEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=s5KwuatT65OeRLDcCIlQ8fwSdhPriji7lupLaOKdm4FuG7EDSSSEk9CPHlo69dhgcl N4CMkd9nX/Z687OhBxpGukwoVAhLLt4jzrlAPUyWzmI9DfoJ6KPZr28ROut3Ktbui/FB K6FtdrRBXhzjEP0q69OhVcRzizTDb94/bTzS4= MIME-Version: 1.0 Received: by 10.42.177.133 with SMTP id bi5mr6889650icb.36.1309166148793; Mon, 27 Jun 2011 02:15:48 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.199.12 with HTTP; Mon, 27 Jun 2011 02:15:48 -0700 (PDT) Date: Mon, 27 Jun 2011 02:15:48 -0700 X-Google-Sender-Auth: -wunLcurHAkjw9zcNBnW50SoaKI Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] agenda plan for 81th meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 09:15:53 -0000 Hello, The schedule is not fixed yet, but we have been given a slot on Wednesday at 9:00-11:30 so far. If you want to present something, please provide us the following info. 1: presenter's name 2: title 3: length of the presentation We believe we can allocate some time for discussing new ideas. So, please don't hesitate to bring up new ideas. Thanks, -- Yoshifumi & Phil From philip.eardley@bt.com Tue Jun 28 00:47:07 2011 Return-Path: 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 3830811E807E for ; Tue, 28 Jun 2011 00:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.045 X-Spam-Level: X-Spam-Status: No, score=-103.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dy+G8UF68b1K for ; Tue, 28 Jun 2011 00:47:04 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id B69D421F863C for ; Tue, 28 Jun 2011 00:47:03 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 28 Jun 2011 08:46:59 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.184]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Tue, 28 Jun 2011 08:46:59 +0100 From: To: , Date: Tue, 28 Jun 2011 08:46:58 +0100 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: AcwsNoAEwA+vzYT/SF6zM7ztidT2sgJLwJ5A Message-ID: <9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F32E13B4472EMV65UKRDdoma_" MIME-Version: 1.0 Cc: thierry.klein@alcatel-lucent.com Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 07:47:07 -0000 --_000_9510D26531EF184D9017DF24659BB87F32E13B4472EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I summarise where I think the discussion (triggered by the email below) has= got to. This is just to test whether we have consensus on how to change th= e protocol draft, so please kick. Firstly, the MP-PRIO message is altered to include Address ID - and (I thin= k) a second flag meaning 'use only this subflow' (not sure discussion fina= lised on this point) Secondly, the other new msgs (see below) suggested by this draft are not ne= eded Thirdly, add some text something like: "An implementation SHOULD send DSS o= ptions that cover multiple segments multiple times, to reduce the need for = unnecessary buffering at the receiver. It is RECOMMENDED that a sender rep= eats the DSS option until a DATA ACK for some data covered by this mapping = is received." Also, there may be some extra /amended discussion about content-altering mi= ddleboxes (I couldn't tell whether the discussion concluded on this point) Sorry where i misunderstood Thanks Phil/ From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Hampel, K Georg (K Georg) Sent: 16 June 2011 16:03 To: multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: [multipathtcp] New I-D: Enhancements to Improve the Applicability = of Multipath TCP to Wireless Access Networks All, We have uploaded a new I-D. Title: Enhancements to Improve the Applicability of Multipath TCP to Wirele= ss Access Networks Authors: Georg Hampel, Thierry Klein Filename: draft-hampel-mptcp-applicability-wireless-networks-00.txt URL: http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-wirel= ess-networks/ Abstract: This document analyses the applicability of Multipath TCP to wireless acces= s networks with overlapping coverage area, and it discusses potential proto= col extensions that aim to improve operation in such environments. The ana= lysis attempts to identify use cases, benefits as well as technical and fun= ctional obstacles encountered in the current version of the protocol. Base= d on this analysis, recommendations are made on feature-, signaling- and po= licy extensions that promise to enhance Multipath-TCP's value, versatility = and market acceptance in wireless access networks. IMPORTANT COMMENTS: Apart from a variety of recommendations for research, t= he I-D proposes the following signaling and policy enhancements: MP_SELECT option: The host sends this option to enforce path-selective operation on its peer.= The option is generally sent on the subflow to be used for data transmiss= ion. It may enclose an address id in case it is sent on another subflow, e.= g. in break-before-make scenarios before the designated path becomes availa= ble. The option permits low-complexity MPTCP receiver solutions (Section 4.= 4) as well as dynamic overhead shedding for heavily loaded servers (Section= 4.5). AVAIL_ADDR/UNAVAIL_ADDR option(s): The host sends this option to inform its peer about the availability/unavai= lability status of an interface referred to via an address id. The enclose= d address-id permits sending the option from an available interface to refe= r to an unavailable interface. The option permits the peer to swiftly adjus= t data transmission when the host's interface availability changes. There a= re multiple use cases for this option (Section 3.6, Section 4.4 and Section= 4.5). DEFER_ADDR option: The host sends this option to instruct its peer to use a specific address r= eferred to via an address id as the destination for all future subflows. Th= is option is required for transparent-proxy operation (section 5). ADD_ADDR option: The present version of this option should be modified: The option should on= ly provide a mapping between address id and address value without further a= dvice or request for action. When the ADD_ADDRESS option refers to the sour= ce address of the packet it is enclosed in, it can omit the address value. = The re-interpretation of this option is necessary to support multiple instr= uctions as provided by the options above (and the one below). JOIN_ADDR option: The host sends this option to request subflow creation (via MP_JOIN) to an = address referred to via the enclosed address id. Currently, the functionali= ty of this option is melted into the ADD_ADDR option. DSS insertion policy for bulk transfer: To reduce receiver complexity, DSS options should be inserted into all pack= ets of a bulk until the first data ACK is received for a packet contained i= n the bulk (Section 3.7). Please take the details from the corresponding sections of the document. Co= mments are welcome. Thank you. Regards, Georg Hampel --_000_9510D26531EF184D9017DF24659BB87F32E13B4472EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

= I summaris= e where I think the discussion (triggered by the email below) has got to. T= his is just to test whether we have consensus on how to change the protocol= draft, so please kick.

Firstly, the MP-PRIO message is a= ltered to include Address ID – and (I think) a second flag meaning &#= 8216;use only this subflow’  (not sure discussion finalised on t= his point)

Secondly, the other new msgs (see below) sugg= ested by this draft are not needed

Thirdly= , add some text something like: “An implementation SHOULD send DSS optio= ns that cover multiple segments multiple times, to reduce the need for unne= cessary buffering at the receiver.  It is RECOMMENDED that a sender re= peats the DSS option until a DATA ACK for some data covered by this mapping= is received.”

Also, there may be som= e extra /amended discussion about content-altering middleboxes (I couldn= 217;t tell whether the discussion concluded on this point)

Sorry where i misunderstood

<= span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif";color:#1F497= D'>Thanks

Phil/

=

 

<= b>From: multipathtcp-bounces@ietf.org [mailto:multipat= htcp-bounces@ietf.org] On Behalf Of Hampel, K Georg (K Georg)
= Sent: 16 June 2011 16:03
To: multipathtcp@ietf.org
Cc:<= /b> Klein, Thierry E (Thierry)
Subject: [multipathtcp] New I-D: E= nhancements to Improve the Applicability of Multipath TCP to Wireless Acces= s Networks

 = ;

All,

 
We have uploaded a new I-D.
 
<= pre>Title: En= hancements to Improve the Applicability of Multipath TCP to Wireless Access= Networks

 

Authors: Georg Hampel, Thierry Klein=

 

Filename: draft-hampel-mptcp-applicability-wireless-networks-00.txt

 

URL: http://datatracker.ietf.or= g/doc/draft-hampel-mptcp-applicability-wireless-networks/

 

Abstr=
act:

This document analyses the applicab= ility of Multipath TCP to wireless access networks with overlapping coverag= e area, and it discusses potential protocol extensions that aim to improve = operation in such environments.  The analysis attempts to identify use= cases, benefits as well as technical and functional obstacles encountered = in the current version of the protocol.  Based on this analysis, recom= mendations are made on feature-, signaling- and policy extensions that prom= ise to enhance Multipath-TCP's value, versatility and market acceptance in = wireless access networks.

 =

 

= IMPORTANT COMMENTS: Apart from a variety of recommendations for research, t= he I-D proposes the following signaling and policy enhancements:

&= nbsp;

MP_SELECT option:

The host sends this option to enforce path-selective operation on i= ts peer.  The option is generally sent on the subflow to be used for d= ata transmission. It may enclose an address id in case it is sent on anothe= r subflow, e.g. in break-before-make scenarios before the designated path b= ecomes available. The option permits low-complexity MPTCP receiver solution= s (Section 4.4) as well as dynamic overhead shedding for heavily loaded ser= vers (Section 4.5).

 

AVAIL_ADDR/UNAVAIL_ADDR option(s):

The host sends this option to inform its peer about the availabilit= y/unavailability status of an interface referred to via an address id. = ; The enclosed address-id permits sending the option from an available inte= rface to refer to an unavailable interface. The option permits the peer to = swiftly adjust data transmission when the host’s interface availabili= ty changes. There are multiple use cases for this option (Section 3.6, Sect= ion 4.4 and Section 4.5).

 =

DEFER_ADDR option:

T= he host sends this option to instruct its peer to use a specific address re= ferred to via an address id as the destination for all future subflows. Thi= s option is required for transparent-proxy operation (section 5).

 

= ADD_ADDR opti= on:

The present version of this option sh= ould be modified: The option should only provide a mapping between address = id and address value without further advice or request for action. When the= ADD_ADDRESS option refers to the source address of the packet it is enclos= ed in, it can omit the address value. The re-interpretation of this option = is necessary to support multiple instructions as provided by the options ab= ove (and the one below).

 <= /span>

JOIN_ADDR option:

The= host sends this option to request subflow creation (via MP_JOIN) to an add= ress referred to via the enclosed address id. Currently, the functionality = of this option is melted into the ADD_ADDR option.

 

DSS insertion policy for bul= k transfer:

To reduce receiver complexity,= DSS options should be inserted into all packets of a bulk until the first = data ACK is received for a packet contained in the bulk (Section 3.7).=

 

&nb= sp;

= Please take the details from the corresponding sections of the document. Co= mments are welcome. Thank you.

 

Regards,

Georg Hampel

 =

 

 

= --_000_9510D26531EF184D9017DF24659BB87F32E13B4472EMV65UKRDdoma_-- From philip.eardley@bt.com Tue Jun 28 01:09:33 2011 Return-Path: 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 4501221F8680 for ; Tue, 28 Jun 2011 01:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.046 X-Spam-Level: X-Spam-Status: No, score=-103.046 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Th7h+-ckujeJ for ; Tue, 28 Jun 2011 01:09:32 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 69EC521F8660 for ; Tue, 28 Jun 2011 01:09:32 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 28 Jun 2011 09:09:30 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.184]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Tue, 28 Jun 2011 09:09:31 +0100 From: To: Date: Tue, 28 Jun 2011 09:09:29 +0100 Thread-Topic: Please help the Nomcom Thread-Index: AcwysIVTu5kMTLs0TkKHhxYZTDBvQACubnEQ Message-ID: <9510D26531EF184D9017DF24659BB87F32E13B44CE@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [multipathtcp] FW: Please help the Nomcom X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 08:09:33 -0000 Y2ZpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB3Z2NoYWlycy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86d2djaGFpcnMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IE5vbUNvbSBDaGFpcg0KU2VudDogMjQgSnVuZSAyMDExIDE5OjM1DQpUbzogV29ya2luZyBHcm91 cCBDaGFpcnMNClN1YmplY3Q6IFBsZWFzZSBoZWxwIHRoZSBOb21jb20gDQoNCkhpIFdHIGNoYWly cywNCiAgV2UgaGF2ZSBoYWQgYSBnb29kIHJlc3BvbnNlIHRvIHRoZSBmaXJzdCBjYWxsIGZvciB2 b2x1bnRlZXJzIGJ1dCB0aGUgDQpyYXRlIGF0IHdoaWNoIG5ldyB2b2x1bnRlZXJzIGFyZSBjb21p bmcgaW4gaXMgc2xvd2luZyBkb3duLiBUaGUgTm9tY29tIA0KcHJvY2VzcyBpcyBiZXN0IHNlcnZl ZCBieSBhIGxhcmdlIHBvb2wgb2Ygdm9sdW50ZWVycyBkcmF3biBmcm9tIGEgd2lkZSANCnNwZWN0 cnVtIG9mIElFVEYgYXR0ZW5kZWVzLiBXaGVyZSBlbHNlIHdvdWxkIHdlIGZpbmQgdGhpcyB3aWRl IHNwZWN0cnVtDQppZiBub3QgaW4gdGhlIFdHIG1haWxpbmcgbGlzdHMuDQoNCkkgd291bGQgcmVh bGx5IGFwcHJlY2lhdGUgaXQgaWYgeW91IGNhbiBmb3J3YXJkIHRoZSBtZXNzYWdlIG9udG8geW91 cg0Kd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3RzLiANCg0KVGhlIGxhdGVzdCB2b2x1bnRlZXIg c3RhdHVzIGFuZCB0aGUgc2Vjb25kIGNhbGwgZm9yIHZvbHVudGVlcnMgY2FuIGJlDQpmb3VuZCBh dA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9hbm4vbm9tY29tLzI5NjQvDQoNClRoYW5r cyBpbiBhZHZhbmNlIGZvciB5b3VyIGhlbHAuDQoNClN1cmVzaCBLcmlzaG5hbg0KTm9tY29tIENo YWlyIDIwMTEtMjAxMg0KRW1haWw6IG5vbWNvbS1jaGFpckBpZXRmLm9yZywgc3VyZXNoLmtyaXNo bmFuQGVyaWNzc29uLmNvbQ0K From georg.hampel@alcatel-lucent.com Tue Jun 28 13:56:29 2011 Return-Path: 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 9D06E11E8112 for ; Tue, 28 Jun 2011 13:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLDmEZC16QF5 for ; Tue, 28 Jun 2011 13:56:24 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 02ED311E80E6 for ; Tue, 28 Jun 2011 13:56:23 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p5SKuIeG026641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Jun 2011 15:56:18 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5SKuGn4020600 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Jun 2011 15:56:17 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 28 Jun 2011 15:56:17 -0500 From: "Hampel, K Georg (K Georg)" To: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Date: Tue, 28 Jun 2011 15:56:15 -0500 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: AcwsNoAEwA+vzYT/SF6zM7ztidT2sgJLwJ5AABvqi2A= Message-ID: <154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC443484E4B0B9USNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 20:56:29 -0000 --_000_154773479ED2314980CB638A48FC443484E4B0B9USNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Phil, all, Below is a summary on the present level of agreement. This summary is not c= omplete but I hope I captured the essential comments. There seems to be con= vergence on some points, others are still open and there are contradicting = opinions on BBM. It may make sense to get as much agreement as possible via= ML prior to the meeting. Thanks. Regards, Georg MP_SELECT: - Alan Ford: 'I guess we could adapt MP_PRIO to achieve this, by h= aving another value that means "use me and me alone". Although I think I n= eed more convincing that it adds value!" - Georg Hampel: This would do the job. The "use me and me alone" M= UST be binding though. AVAIL/UNAVAIL_ADDRESS: - Alan Ford: 'If we were to modify the MP_PRIO option to take an A= ddress ID (which is something we've thought about doing before but the use = cases were not clear), then you could downgrade one path from another. That= may be sufficient (at least, with tolerant flow control). Shortcuts of a = second bit to say "Do not use" or "use exclusively" could also help here.' - Georg Hampel: MP_PRIO with Address ID changes the semantic mean= ing since it refers to an address rather than a path. I'm fine with this as= long as everybody is aware of it. We may have to file out the details. - Joe Touch: "I think the key would be to focus on the fact that t= hese are addresses, and include a brief discussion on the limitations of th= e approach - i.e., it works for only directly attached interfaces". Joe fur= ther recommended to cite trigtran work in this context. DEFER_ADDR: - Alan Ford: I don't see the point of JOIN_ADDR and ADD_ADDR separ= ations, but DEFER_ADDR (or "USE_THIS_ADDR!") is an interesting idea that I = need to think about some more! - Georg Hampel: USE_THIS_ADDR instead of DEFER_ADDR is fine with m= e and may even be clearer. ADD_ADDRESS: - Christoph Paasch: "I don't see a case where the ADD_ADDR-option = is sent, refering to the packet's source address, because the address-id of= this source-address has already been provided by the MP_JOIN when establis= hing the subflow. - Georg Hampel: That's right I've overseen this. JOIN_ADDRESS to be separated from ADD_ADDR: - Georg Hampel: We still need to separate these two functions to s= upport DEFER_ADDR (or USE_THIS_ADDR) unless the latter options include the = address value explicitly. Break before make: NOT CLARIFIED!!! - Georg Hampel: If host undergoes lower-layer BBM, it should send = RST on the old interface to close state on middleboxes. - Yoshifumi Nishida: "I think L4 should be conservative to react o= n L2/L3 incidents, so I'm a bit skeptical about sending RST here." - Olivier Bonaventure: "In the case that you mentioned, the host s= hould not send a RST when it looses connectivity. Instead, it should leave = the MPTCP session up, switch to the new address and send an MP_JOIN. After = that, it can use REMOVE_ADDR to indicate that the old address does not work= anymore (section 3.4). - According to Christoph Paasch lower-layer BBM should lead to sub= flow discontinuation since it is not certain that middleboxes will keep sta= te in case the interface is re-connected. - Georg Hampel: Christoph's statement means that the host must sen= d RST since it cannot count on its peer to react to FIN. - to be continued... DSS insertion policy for bulk transfer: NEEDS MORE DISCUSSION - Alan Ford: "An implementation SHOULD send DSS options that cover= multiple segments multiple times, to reduce the need for unnecessary buffe= ring at the receiver. It is RECOMMENDED that a sender repeats the DSS opti= on until a DATA ACK for some data covered by this mapping is received." - Georg Hampel: We need this to avoid an additional out-of-order q= ueue for path-selective operation. - Christoph Paasch had longer comments on this... ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Tuesday, June 28, 2011 3:47 AM To: Hampel, K Georg (K Georg); multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi, I summarise where I think the discussion (triggered by the email below) has= got to. This is just to test whether we have consensus on how to change th= e protocol draft, so please kick. Firstly, the MP-PRIO message is altered to include Address ID - and (I thin= k) a second flag meaning 'use only this subflow' (not sure discussion fina= lised on this point) Secondly, the other new msgs (see below) suggested by this draft are not ne= eded Thirdly, add some text something like: "An implementation SHOULD send DSS o= ptions that cover multiple segments multiple times, to reduce the need for = unnecessary buffering at the receiver. It is RECOMMENDED that a sender rep= eats the DSS option until a DATA ACK for some data covered by this mapping = is received." Also, there may be some extra /amended discussion about content-altering mi= ddleboxes (I couldn't tell whether the discussion concluded on this point) Sorry where i misunderstood Thanks Phil/ From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of Hampel, K Georg (K Georg) Sent: 16 June 2011 16:03 To: multipathtcp@ietf.org Cc: Klein, Thierry E (Thierry) Subject: [multipathtcp] New I-D: Enhancements to Improve the Applicability = of Multipath TCP to Wireless Access Networks All, We have uploaded a new I-D. Title: Enhancements to Improve the Applicability of Multipath TCP to Wirele= ss Access Networks Authors: Georg Hampel, Thierry Klein Filename: draft-hampel-mptcp-applicability-wireless-networks-00.txt URL: http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-wirel= ess-networks/ Abstract: This document analyses the applicability of Multipath TCP to wireless acces= s networks with overlapping coverage area, and it discusses potential proto= col extensions that aim to improve operation in such environments. The ana= lysis attempts to identify use cases, benefits as well as technical and fun= ctional obstacles encountered in the current version of the protocol. Base= d on this analysis, recommendations are made on feature-, signaling- and po= licy extensions that promise to enhance Multipath-TCP's value, versatility = and market acceptance in wireless access networks. IMPORTANT COMMENTS: Apart from a variety of recommendations for research, t= he I-D proposes the following signaling and policy enhancements: MP_SELECT option: The host sends this option to enforce path-selective operation on its peer.= The option is generally sent on the subflow to be used for data transmiss= ion. It may enclose an address id in case it is sent on another subflow, e.= g. in break-before-make scenarios before the designated path becomes availa= ble. The option permits low-complexity MPTCP receiver solutions (Section 4.= 4) as well as dynamic overhead shedding for heavily loaded servers (Section= 4.5). AVAIL_ADDR/UNAVAIL_ADDR option(s): The host sends this option to inform its peer about the availability/unavai= lability status of an interface referred to via an address id. The enclose= d address-id permits sending the option from an available interface to refe= r to an unavailable interface. The option permits the peer to swiftly adjus= t data transmission when the host's interface availability changes. There a= re multiple use cases for this option (Section 3.6, Section 4.4 and Section= 4.5). DEFER_ADDR option: The host sends this option to instruct its peer to use a specific address r= eferred to via an address id as the destination for all future subflows. Th= is option is required for transparent-proxy operation (section 5). ADD_ADDR option: The present version of this option should be modified: The option should on= ly provide a mapping between address id and address value without further a= dvice or request for action. When the ADD_ADDRESS option refers to the sour= ce address of the packet it is enclosed in, it can omit the address value. = The re-interpretation of this option is necessary to support multiple instr= uctions as provided by the options above (and the one below). JOIN_ADDR option: The host sends this option to request subflow creation (via MP_JOIN) to an = address referred to via the enclosed address id. Currently, the functionali= ty of this option is melted into the ADD_ADDR option. DSS insertion policy for bulk transfer: To reduce receiver complexity, DSS options should be inserted into all pack= ets of a bulk until the first data ACK is received for a packet contained i= n the bulk (Section 3.7). Please take the details from the corresponding sections of the document. Co= mments are welcome. Thank you. Regards, Georg Hampel --_000_154773479ED2314980CB638A48FC443484E4B0B9USNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Phil, all,

 

Below is a summary on the present level of agreement. Th= is summary is not complete but I hope I captured the essential comments. There seems to be convergence on some points, others are still open and there are contradicting opinions on BBM. It may make sense to get as much agreement a= s possible via ML prior to the meeting. Thanks.

 

Regards,

Georg

 

 

MP_SELECT:

-      =     Alan Ford: ‘= ;I guess we could adapt MP_PRIO to achieve this, by having another value that means = 220;use me and me alone”.  Although I think I need more convincing that it = adds value!”

-      =     Georg Hampel: This would do th= e job. The “use me and me alone” MUST be binding though.

 

AVAIL/UNAVAIL_ADDRESS:

- = ;         Alan Ford: ‘If we were to modify the MP_PRIO option to take an Address ID (which is someth= ing we’ve thought about doing before but the use cases were not clear), t= hen you could downgrade one path from another. That may be sufficient (at least, wi= th tolerant flow control).  Shortcuts of a second bit to say “Do no= t use” or “use exclusively” could also help here.’

-      =     Georg Hampel:&nbs= p; MP_PRIO with Address ID changes the semantic meaning since it refers to an address rather than a path. I’m fine with this as long as everybody is aware = of it. We may have to file out the details.=

-      =     Joe Touch: “I think the = key would be to focus on the fact that these are addresses, and include a brief discussi= on on the limitations of the approach - i.e., it works for only directly attac= hed interfaces”. Joe further recommended to cite trigtran work in this co= ntext.

 

DEFER_ADDR:

- = ;         Alan Ford: I don&= #8217;t see the point of JOIN_ADDR and ADD_ADDR separations, but DEFER_ADDR (or “USE_THIS_ADDR!”) is an interesting idea that I need to think a= bout some more!

-      =     Georg Hampel: USE_THIS_ADDR instead of DEFER_ADDR is fine with me and may even be clearer= .

 

ADD_ADDRESS:

-          Christoph Paasch: “I don= 't see a case where the ADD_ADDR-option is sent, refering to the packet's source address, because the address-id of this source-address has already been provided by the MP_JOIN when establishing the subflow.

-          Georg Hampel: That’s rig= ht I’ve overseen this.

 

JOIN_ADDRESS to be separated f= rom ADD_ADDR:

-          Georg Hampel: We still need to separate these two functions to support DEFER_ADDR (or USE_THIS_ADDR) unles= s the latter options include the address value explicitly.

 

Break before make: NOT CLARIFIED!!!

-          Georg Hampel: If host undergoe= s lower-layer BBM, it should send RST on the old interface to close state on middleboxes.

-          Yoshifumi Nishida: “I th= ink L4 should be conservative to react on L2/L3 incidents, so I'm a bit skeptical about sending RST here.”

-          Olivier Bonaventure: “In= the case that you mentioned, the host should not send a RST when it looses connectiv= ity. Instead, it should leave the MPTCP session up, switch to the new address an= d send an MP_JOIN. After that, it can use REMOVE_ADDR to indicate that the ol= d address does not work anymore (section 3.4).

-      =     According to Christoph Paasch lower-layer BBM should lead to subflow discontinuation since it is not cert= ain that middleboxes will keep state in case the interface is re-connected.

-      =     Georg Hampel: Christoph’= s statement means that the host must send RST since it cannot count on its peer to reac= t to FIN.

-      =     to be continued…

 

DSS insertion policy for bulk transfer: NEEDS MORE DISCUSSION

- = ;         Alan Ford: “= ;An implementation SHOULD send DSS options that cover multiple segments multipl= e times, to reduce the need for unnecessary buffering at the receiver.  = It is RECOMMENDED that a sender repeats the DSS option until a DATA ACK for so= me data covered by this mapping is received.”

- = ;         Georg Hampel: We = need this to avoid an additional out-of-order queue for path-selective operation= .

- = ;         Christoph Paasch = had longer comments on this…

 

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: Tuesday, June 28, 2011= 3:47 AM
To: Hampel, K Georg (K Georg= ); multipathtcp@ietf.org
Cc: Klein, Thierry E (Thierr= y)
Subject: RE: [multipathtcp] = New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks=

 

Hi,

I summarise where I think the discussion (triggered by the email below) has got to. This is just to test whether we = have consensus on how to change the protocol draft, so please kick.

Firstly, the MP-PRIO message is altered = to include Address ID – and (I think) a second flag meaning ‘use o= nly this subflow’  (not sure discussion finalised on this point)

Secondly, the other new msgs (see below) suggested by this draft are not needed

Thirdly, add s= ome text something like: “An implementation SHOULD send DSS options that = cover multiple segments multiple times, to reduce the need for unnecessary buffer= ing at the receiver.  It is RECOMMENDED that a sender repeats the DSS opti= on until a DATA ACK for some data covered by this mapping is received.”<= o:p>

Also, there may be some extra /amended discussion about content-altering middleboxes (I couldn’t tell whethe= r the discussion concluded on this point)

Sorry where i misunderstood

Thanks

Phil/

 

From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Hampel, K Georg (K Georg= )
Sent: 16 June 2011 16:03
To: multipathtcp@ietf.org Cc: Klein, Thierry E (Thierr= y)
Subject: [multipathtcp] New = I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Acce= ss Networks

 

All,

 
We=
 have uploaded a new I-D.
 
Ti=
tle: Enhancements to Improve the Applicability of Multipath TCP to Wireless=
 Access Networks

 

Authors: Georg Hampel, Thierry= Klein

 

Filename: draft-hampel-mptcp-applicability-wireless-networks-00.tx=
t

 

URL: http://datatracker.ietf.org/doc/draft-hampel-mptcp-applic= ability-wireless-networks/

 

Abstract:

This document analyses the applicability of Multipath TC= P to wireless access networks with overlapping coverage area, and it discusses potential protocol extensions that aim to improve operation in such environments.  The analysis attempts to identify use cases, benefits a= s well as technical and functional obstacles encountered in the current versi= on of the protocol.  Based on this analysis, recommendations are made on feature-, signaling- and policy extensions that promise to enhance Multipath-TCP's value, versatility and market acceptance in wireless access= networks.

 

 

IMPORTANT COMMENTS: Apart from a variety of recommendati= ons for research, the I-D proposes the following signaling and policy enhanceme= nts:

 

MP_SELECT option:

The host sends this option to enforce path-selective operation on its peer.  The option is generally sent on the subflow to= be used for data transmission. It may enclose an address id in case it is sent= on another subflow, e.g. in break-before-make scenarios before the designated = path becomes available. The option permits low-complexity MPTCP receiver solutio= ns (Section 4.4) as well as dynamic overhead shedding for heavily loaded serve= rs (Section 4.5).

 

AVAIL_ADDR/UNAVAIL_ADDR option(s):

The host sends this option to inform its peer about the availability/unavailability status of an interface referred to via an addre= ss id.  The enclosed address-id permits sending the option from an availa= ble interface to refer to an unavailable interface. The option permits the peer= to swiftly adjust data transmission when the host’s interface availabili= ty changes. There are multiple use cases for this option (Section 3.6, Section 4.4 and Section 4.5).

 

DEFER_ADDR option:

The host sends this option to instruct its peer to use a specific address referred to via an address id as the destination for all future subflows. This option is required for transparent-proxy operation (section 5).

 

ADD_ADDR option:

The present version of this option should be modified: T= he option should only provide a mapping between address id and address value without further advice or request for action. When the ADD_ADDRESS option refers to the source address of the packet it is enclosed in, it can omit t= he address value. The re-interpretation of this option is necessary to support multiple instructions as provided by the options above (and the one below).=

 

JOIN_ADDR option:

The host sends this option to request subflow creation (= via MP_JOIN) to an address referred to via the enclosed address id. Currently, = the functionality of this option is melted into the ADD_ADDR option.=

 

DSS insertion policy for bulk transfer:

To reduce receiver complexity, DSS options should be inserted into all packets of a bulk until the first data ACK is received fo= r a packet contained in the bulk (Section 3.7).

 

 

Please take the details from t= he corresponding sections of the document. Comments are welcome. Thank you.

 

Regards,

Georg Hampel=

 

 

 

--_000_154773479ED2314980CB638A48FC443484E4B0B9USNAVSXCHMBSA2n_-- From olivier.bonaventure@uclouvain.be Wed Jun 29 00:34:19 2011 Return-Path: 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 2AEEC21F86E4 for ; Wed, 29 Jun 2011 00:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIGEBHgwyKpM for ; Wed, 29 Jun 2011 00:34:18 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE4521F86B4 for ; Wed, 29 Jun 2011 00:34:18 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id F39B711E1B1; Wed, 29 Jun 2011 09:34:13 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be F39B711E1B1 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1309332854; bh=CD7+FEHCJhUduwQASUcYy3VOX/8XXnkJYNHSOmV7PuU=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=G13GEoswPjGAomXbfBGuPyAn8aPExWyTOzOx/Sr/MimoFprItdk4nNAION++hUFyW qwMwdbXHT6POjV+yu6aRF3IgYxgegJX9X+/01zc3MafKK+lyyhjfEhC7Kh0DEYebSK LoicPaa5dNVptO0/sZENOtaLK9EcDZm8favcfz28= Message-ID: <4E0AD572.3090401@uclouvain.be> Date: Wed, 29 Jun 2011 09:34:10 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b3pre Thunderbird/3.1.11 MIME-Version: 1.0 To: "Ford, Alan" References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <2181C5F19DD0254692452BFF3EAF1D680D15D18D@rsys005a.comm.ad.roke.co.uk> In-Reply-To: <2181C5F19DD0254692452BFF3EAF1D680D15D18D@rsys005a.comm.ad.roke.co.uk> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: F39B711E1B1.A327B X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp@ietf.org, "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 07:34:19 -0000 Alan, > 3.7: This idea is sensible, but I would be reluctant to mandate it. I > think some text like this may be sufficient: “An implementation SHOULD > send DSS options that cover multiple segments multiple times, to reduce > the need for unnecessary buffering at the receiver. It is RECOMMENDED > that a sender repeats the DSS option until a DATA ACK for some data > covered by this mapping is received.” I would suggest to wait until we get more experience with the MPTCP implementations and their behaviour in the real Internet before discussing optimisations like this one. A reasonable solution based on our understanding of the operations of MPTCP today is to put a DSS option inside each segment. I would suggest to put text that recommends experiments with lower frequency transmission of the DSS option but would wait for the results of these experiments before mandating anything in the spec. There are subtle interactions between DSS and the TCP segment offload capable itnerfaces that need to be analysed before mandating anything on this Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From philip.eardley@bt.com Wed Jun 29 00:50:18 2011 Return-Path: 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 507F121F8532 for ; Wed, 29 Jun 2011 00:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.045 X-Spam-Level: X-Spam-Status: No, score=-103.045 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEGJRpfRvFu1 for ; Wed, 29 Jun 2011 00:50:17 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id AC76E21F851D for ; Wed, 29 Jun 2011 00:50:16 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 29 Jun 2011 08:49:00 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.184]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Wed, 29 Jun 2011 08:49:00 +0100 From: To: Date: Wed, 29 Jun 2011 08:48:59 +0100 Thread-Topic: Moving the MPTCP meeting at ietf-81 Thread-Index: Acw2MQGI2M0wvLqpTX6iENws8pvlqQ== Message-ID: <9510D26531EF184D9017DF24659BB87F32E14C56A5@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F32E14C56A5EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] Moving the MPTCP meeting at ietf-81 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 07:50:18 -0000 --_000_9510D26531EF184D9017DF24659BB87F32E14C56A5EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There has been a request to swap with tsvwg, so mptcp would be Fri morning = (instead of Wed) If this creates conflicts for anyone, please shout NOW Thanks Phil & Yoshifumi --_000_9510D26531EF184D9017DF24659BB87F32E14C56A5EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There has been a= request to swap with tsvwg, so mptcp would be Fri morning (instead of Wed)=

If this creates conflicts for anyone, p= lease shout NOW

 

Thanks

Phil & Yosh= ifumi

= --_000_9510D26531EF184D9017DF24659BB87F32E14C56A5EMV65UKRDdoma_-- From yoshifumi.nishida@gmail.com Wed Jun 29 03:09:44 2011 Return-Path: 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 3CEC89E803B for ; Wed, 29 Jun 2011 03:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nc6p3Xe2nXDg for ; Wed, 29 Jun 2011 03:09:42 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3804821F85AF for ; Wed, 29 Jun 2011 03:09:42 -0700 (PDT) Received: by iye7 with SMTP id 7so1188283iye.31 for ; Wed, 29 Jun 2011 03:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GTy96PNIApwzgdOyi9xSDPrbNoEWAQ03tiEt6PCBcvo=; b=gQQ81MHduRLs+MMWP0W8wIJ/pEtsgbOMRytR6O0FNFYATRN/wOAwkJ0YbPazdzo/fR zOWDxa5xlijH059hZ6HA3bXeI0G8l5EsYlFhRcPNjuBTkjz82RsIKya5U/AaHi+/z4vE 8s21AbAz/Aswds15vZV9RTlxsvbSwfaLdVLcU= MIME-Version: 1.0 Received: by 10.231.41.69 with SMTP id n5mr562607ibe.83.1309342175578; Wed, 29 Jun 2011 03:09:35 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.199.12 with HTTP; Wed, 29 Jun 2011 03:09:35 -0700 (PDT) In-Reply-To: <154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Date: Wed, 29 Jun 2011 03:09:35 -0700 X-Google-Sender-Auth: sh0PA-nn51Nj9Aye0ioZfjv2bxA Message-ID: From: Yoshifumi Nishida To: "Hampel, K Georg (K Georg)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 10:09:44 -0000 Hi Georg, Thanks for the summary. Could you elaborate the binding in MP_SELECT? I'm wondering how a peer has a strong control to the other peer. If the other peer disagree with it, what will happen? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/6/28 Hampel, K Georg (K Georg) : > Hi Phil, all, > > > > Below is a summary on the present level of agreement. This summary is not > complete but I hope I captured the essential comments. There seems to be > convergence on some points, others are still open and there are > contradicting opinions on BBM. It may make sense to get as much agreement= as > possible via ML prior to the meeting. Thanks. > > > > Regards, > > Georg > > > > > > MP_SELECT: > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Alan Ford: =91I guess we could adapt MP_PRIO= to achieve this, by > having another value that means =93use me and me alone=94.=A0 Although I = think I > need more convincing that it adds value!=94 > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Georg Hampel: This would do the job. The =93= use me and me alone=94 > MUST be binding though. > > > > AVAIL/UNAVAIL_ADDRESS: > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Alan Ford: =91If we were to modify the MP_PR= IO option to take an > Address ID (which is something we=92ve thought about doing before but the= use > cases were not clear), then you could downgrade one path from another. Th= at > may be sufficient (at least, with tolerant flow control).=A0 Shortcuts of= a > second bit to say =93Do not use=94 or =93use exclusively=94 could also he= lp here.=92 > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Georg Hampel:=A0 MP_PRIO with Address ID cha= nges the semantic > meaning since it refers to an address rather than a path. I=92m fine with= this > as long as everybody is aware of it. We may have to file out the details. > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Joe Touch: =93I think the key would be to fo= cus on the fact that > these are addresses, and include a brief discussion on the limitations of > the approach - i.e., it works for only directly attached interfaces=94. J= oe > further recommended to cite trigtran work in this context. > > > > DEFER_ADDR: > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Alan Ford: I don=92t see the point of JOIN_A= DDR and ADD_ADDR > separations, but DEFER_ADDR (or =93USE_THIS_ADDR!=94) is an interesting i= dea > that I need to think about some more! > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Georg Hampel: USE_THIS_ADDR instead of DEFER= _ADDR is fine with me > and may even be clearer. > > > > ADD_ADDRESS: > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Christoph Paasch: =93I don't see a case wher= e the ADD_ADDR-option > is sent, refering to the packet's source address, because the address-id = of > this source-address has already been provided by the MP_JOIN when > establishing the subflow. > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Georg Hampel: That=92s right I=92ve overseen= this. > > > > JOIN_ADDRESS to be separated from ADD_ADDR: > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Georg Hampel: We still need to separate thes= e two functions to > support DEFER_ADDR (or USE_THIS_ADDR) unless the latter options include t= he > address value explicitly. > > > > Break before make: NOT CLARIFIED!!! > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Georg Hampel: If host undergoes lower-layer = BBM, it should send > RST on the old interface to close state on middleboxes. > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Yoshifumi Nishida: =93I think L4 should be c= onservative to react on > L2/L3 incidents, so I'm a bit skeptical about sending RST here.=94 > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Olivier Bonaventure: =93In the case that you= mentioned, the host > should not send a RST when it looses connectivity. Instead, it should lea= ve > the MPTCP session up, switch to the new address and send an MP_JOIN. Afte= r > that, it can use REMOVE_ADDR to indicate that the old address does not wo= rk > anymore (section 3.4). > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 According to Christoph Paasch lower-layer BB= M should lead to > subflow discontinuation since it is not certain that middleboxes will kee= p > state in case the interface is re-connected. > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Georg Hampel: Christoph=92s statement means = that the host must send > RST since it cannot count on its peer to react to FIN. > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 to be continued=85 > > > > DSS insertion policy for bulk transfer: NEEDS MORE DISCUSSION > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Alan Ford: =93An implementation SHOULD send = DSS options that cover > multiple segments multiple times, to reduce the need for unnecessary > buffering at the receiver.=A0 It is RECOMMENDED that a sender repeats the= DSS > option until a DATA ACK for some data covered by this mapping is received= .=94 > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Georg Hampel: We need this to avoid an addit= ional out-of-order > queue for path-selective operation. > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Christoph Paasch had longer comments on this= =85 > > > > > > ________________________________ > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Tuesday, June 28, 2011 3:47 AM > To: Hampel, K Georg (K Georg); multipathtcp@ietf.org > > Cc: Klein, Thierry E (Thierry) > Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the > Applicability of Multipath TCP to Wireless Access Networks > > > > Hi, > > I summarise where I think the discussion (triggered by the email below) h= as > got to. This is just to test whether we have consensus on how to change t= he > protocol draft, so please kick. > > Firstly, the MP-PRIO message is altered to include Address ID =96 and (I > think) a second flag meaning =91use only this subflow=92 =A0(not sure dis= cussion > finalised on this point) > > Secondly, the other new msgs (see below) suggested by this draft are not > needed > > Thirdly, add some text something like: =93An implementation SHOULD send D= SS > options that cover multiple segments multiple times, to reduce the need f= or > unnecessary buffering at the receiver.=A0 It is RECOMMENDED that a sender > repeats the DSS option until a DATA ACK for some data covered by this > mapping is received.=94 > > Also, there may be some extra /amended discussion about content-altering > middleboxes (I couldn=92t tell whether the discussion concluded on this p= oint) > > Sorry where i misunderstood > > Thanks > > Phil/ > > > > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org= ] > On Behalf Of Hampel, K Georg (K Georg) > Sent: 16 June 2011 16:03 > To: multipathtcp@ietf.org > Cc: Klein, Thierry E (Thierry) > Subject: [multipathtcp] New I-D: Enhancements to Improve the Applicabilit= y > of Multipath TCP to Wireless Access Networks > > > > All, > > > > We have uploaded a new I-D. > > > > Title: Enhancements to Improve the Applicability of Multipath TCP to > Wireless Access Networks > > > > Authors: Georg Hampel, Thierry Klein > > > > Filename: draft-hampel-mptcp-applicability-wireless-networks-00.txt > > > > URL: > http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-wireless= -networks/ > > > > Abstract: > > This document analyses the applicability of Multipath TCP to wireless acc= ess > networks with overlapping coverage area, and it discusses potential proto= col > extensions that aim to improve operation in such environments.=A0 The ana= lysis > attempts to identify use cases, benefits as well as technical and functio= nal > obstacles encountered in the current version of the protocol.=A0 Based on= this > analysis, recommendations are made on feature-, signaling- and policy > extensions that promise to enhance Multipath-TCP's value, versatility and > market acceptance in wireless access networks. > > > > > > IMPORTANT COMMENTS: Apart from a variety of recommendations for research, > the I-D proposes the following signaling and policy enhancements: > > > > MP_SELECT option: > > The host sends this option to enforce path-selective operation on its pee= r. > The option is generally sent on the subflow to be used for data > transmission. It may enclose an address id in case it is sent on another > subflow, e.g. in break-before-make scenarios before the designated path > becomes available. The option permits low-complexity MPTCP receiver > solutions (Section 4.4) as well as dynamic overhead shedding for heavily > loaded servers (Section 4.5). > > > > AVAIL_ADDR/UNAVAIL_ADDR option(s): > > The host sends this option to inform its peer about the > availability/unavailability status of an interface referred to via an > address id.=A0 The enclosed address-id permits sending the option from an > available interface to refer to an unavailable interface. The option perm= its > the peer to swiftly adjust data transmission when the host=92s interface > availability changes. There are multiple use cases for this option (Secti= on > 3.6, Section 4.4 and Section 4.5). > > > > DEFER_ADDR option: > > The host sends this option to instruct its peer to use a specific address > referred to via an address id as the destination for all future subflows. > This option is required for transparent-proxy operation (section 5). > > > > ADD_ADDR option: > > The present version of this option should be modified: The option should > only provide a mapping between address id and address value without furth= er > advice or request for action. When the ADD_ADDRESS option refers to the > source address of the packet it is enclosed in, it can omit the address > value. The re-interpretation of this option is necessary to support multi= ple > instructions as provided by the options above (and the one below). > > > > JOIN_ADDR option: > > The host sends this option to request subflow creation (via MP_JOIN) to a= n > address referred to via the enclosed address id. Currently, the > functionality of this option is melted into the ADD_ADDR option. > > > > DSS insertion policy for bulk transfer: > > To reduce receiver complexity, DSS options should be inserted into all > packets of a bulk until the first data ACK is received for a packet > contained in the bulk (Section 3.7). > > > > > > Please take the details from the corresponding sections of the document. > Comments are welcome. Thank you. > > > > Regards, > > Georg Hampel > > > > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > From c.raiciu@cs.ucl.ac.uk Wed Jun 29 07:05:57 2011 Return-Path: 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 3601511E8079 for ; Wed, 29 Jun 2011 07:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfQxBcoFfQ69 for ; Wed, 29 Jun 2011 07:05:56 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by ietfa.amsl.com (Postfix) with ESMTP id A7BB411E807F for ; Wed, 29 Jun 2011 07:05:55 -0700 (PDT) Received: from [12.176.20.2] (helo=[172.17.165.215]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1QbvOe-000NtO-Hv; Wed, 29 Jun 2011 15:05:41 +0100 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Costin Raiciu In-Reply-To: Date: Wed, 29 Jun 2011 10:05:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.1081) Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 14:05:57 -0000 Going further, I would argue that there is no point to make this path = preference binding for the other endhost. I think the other host SHOULD = use this information if possible. If this is not possible, and the = receving host feels so strong about path preference, it can always drop = the subflow, or send congestion marks.=20 Re: BBM. I don't see it as contentious - as Olivier and Yoshifumi = mention, the host should not reset subflows when the interface dies ; it = should let the transport stack time out the corresponding subflow. Re: Christoph's note about middelboxes timing out state: that is also = true for silent flow (e.g. an ssh session not use for a few minutes). It = is orthogonal to BBM, and if it happens the flow will crash miserably = and does today's SSH, and that;'s that. Cheers, Cosin On 29 Jun 2011, at 06:09, Yoshifumi Nishida wrote: > Hi Georg, >=20 > Thanks for the summary. Could you elaborate the binding in MP_SELECT? > I'm wondering how a peer has a strong control to the other peer. > If the other peer disagree with it, what will happen? >=20 > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp >=20 > 2011/6/28 Hampel, K Georg (K Georg) : >> Hi Phil, all, >>=20 >>=20 >>=20 >> Below is a summary on the present level of agreement. This summary is = not >> complete but I hope I captured the essential comments. There seems to = be >> convergence on some points, others are still open and there are >> contradicting opinions on BBM. It may make sense to get as much = agreement as >> possible via ML prior to the meeting. Thanks. >>=20 >>=20 >>=20 >> Regards, >>=20 >> Georg >>=20 >>=20 >>=20 >>=20 >>=20 >> MP_SELECT: >>=20 >> - Alan Ford: =91I guess we could adapt MP_PRIO to achieve = this, by >> having another value that means =93use me and me alone=94. Although = I think I >> need more convincing that it adds value!=94 >>=20 >> - Georg Hampel: This would do the job. The =93use me and me = alone=94 >> MUST be binding though. >>=20 >>=20 >>=20 >> AVAIL/UNAVAIL_ADDRESS: >>=20 >> - Alan Ford: =91If we were to modify the MP_PRIO option to = take an >> Address ID (which is something we=92ve thought about doing before but = the use >> cases were not clear), then you could downgrade one path from = another. That >> may be sufficient (at least, with tolerant flow control). Shortcuts = of a >> second bit to say =93Do not use=94 or =93use exclusively=94 could = also help here.=92 >>=20 >> - Georg Hampel: MP_PRIO with Address ID changes the = semantic >> meaning since it refers to an address rather than a path. I=92m fine = with this >> as long as everybody is aware of it. We may have to file out the = details. >>=20 >> - Joe Touch: =93I think the key would be to focus on the = fact that >> these are addresses, and include a brief discussion on the = limitations of >> the approach - i.e., it works for only directly attached interfaces=94.= Joe >> further recommended to cite trigtran work in this context. >>=20 >>=20 >>=20 >> DEFER_ADDR: >>=20 >> - Alan Ford: I don=92t see the point of JOIN_ADDR and = ADD_ADDR >> separations, but DEFER_ADDR (or =93USE_THIS_ADDR!=94) is an = interesting idea >> that I need to think about some more! >>=20 >> - Georg Hampel: USE_THIS_ADDR instead of DEFER_ADDR is fine = with me >> and may even be clearer. >>=20 >>=20 >>=20 >> ADD_ADDRESS: >>=20 >> - Christoph Paasch: =93I don't see a case where the = ADD_ADDR-option >> is sent, refering to the packet's source address, because the = address-id of >> this source-address has already been provided by the MP_JOIN when >> establishing the subflow. >>=20 >> - Georg Hampel: That=92s right I=92ve overseen this. >>=20 >>=20 >>=20 >> JOIN_ADDRESS to be separated from ADD_ADDR: >>=20 >> - Georg Hampel: We still need to separate these two = functions to >> support DEFER_ADDR (or USE_THIS_ADDR) unless the latter options = include the >> address value explicitly. >>=20 >>=20 >>=20 >> Break before make: NOT CLARIFIED!!! >>=20 >> - Georg Hampel: If host undergoes lower-layer BBM, it should = send >> RST on the old interface to close state on middleboxes. >>=20 >> - Yoshifumi Nishida: =93I think L4 should be conservative to = react on >> L2/L3 incidents, so I'm a bit skeptical about sending RST here.=94 >>=20 >> - Olivier Bonaventure: =93In the case that you mentioned, = the host >> should not send a RST when it looses connectivity. Instead, it should = leave >> the MPTCP session up, switch to the new address and send an MP_JOIN. = After >> that, it can use REMOVE_ADDR to indicate that the old address does = not work >> anymore (section 3.4). >>=20 >> - According to Christoph Paasch lower-layer BBM should lead = to >> subflow discontinuation since it is not certain that middleboxes will = keep >> state in case the interface is re-connected. >>=20 >> - Georg Hampel: Christoph=92s statement means that the host = must send >> RST since it cannot count on its peer to react to FIN. >>=20 >> - to be continued=85 >>=20 >>=20 >>=20 >> DSS insertion policy for bulk transfer: NEEDS MORE DISCUSSION >>=20 >> - Alan Ford: =93An implementation SHOULD send DSS options = that cover >> multiple segments multiple times, to reduce the need for unnecessary >> buffering at the receiver. It is RECOMMENDED that a sender repeats = the DSS >> option until a DATA ACK for some data covered by this mapping is = received.=94 >>=20 >> - Georg Hampel: We need this to avoid an additional = out-of-order >> queue for path-selective operation. >>=20 >> - Christoph Paasch had longer comments on this=85 >>=20 >>=20 >>=20 >>=20 >>=20 >> ________________________________ >>=20 >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >> Sent: Tuesday, June 28, 2011 3:47 AM >> To: Hampel, K Georg (K Georg); multipathtcp@ietf.org >>=20 >> Cc: Klein, Thierry E (Thierry) >> Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the >> Applicability of Multipath TCP to Wireless Access Networks >>=20 >>=20 >>=20 >> Hi, >>=20 >> I summarise where I think the discussion (triggered by the email = below) has >> got to. This is just to test whether we have consensus on how to = change the >> protocol draft, so please kick. >>=20 >> Firstly, the MP-PRIO message is altered to include Address ID =96 and = (I >> think) a second flag meaning =91use only this subflow=92 (not sure = discussion >> finalised on this point) >>=20 >> Secondly, the other new msgs (see below) suggested by this draft are = not >> needed >>=20 >> Thirdly, add some text something like: =93An implementation SHOULD = send DSS >> options that cover multiple segments multiple times, to reduce the = need for >> unnecessary buffering at the receiver. It is RECOMMENDED that a = sender >> repeats the DSS option until a DATA ACK for some data covered by this >> mapping is received.=94 >>=20 >> Also, there may be some extra /amended discussion about = content-altering >> middleboxes (I couldn=92t tell whether the discussion concluded on = this point) >>=20 >> Sorry where i misunderstood >>=20 >> Thanks >>=20 >> Phil/ >>=20 >>=20 >>=20 >> From: multipathtcp-bounces@ietf.org = [mailto:multipathtcp-bounces@ietf.org] >> On Behalf Of Hampel, K Georg (K Georg) >> Sent: 16 June 2011 16:03 >> To: multipathtcp@ietf.org >> Cc: Klein, Thierry E (Thierry) >> Subject: [multipathtcp] New I-D: Enhancements to Improve the = Applicability >> of Multipath TCP to Wireless Access Networks >>=20 >>=20 >>=20 >> All, >>=20 >>=20 >>=20 >> We have uploaded a new I-D. >>=20 >>=20 >>=20 >> Title: Enhancements to Improve the Applicability of Multipath TCP to >> Wireless Access Networks >>=20 >>=20 >>=20 >> Authors: Georg Hampel, Thierry Klein >>=20 >>=20 >>=20 >> Filename: draft-hampel-mptcp-applicability-wireless-networks-00.txt >>=20 >>=20 >>=20 >> URL: >> = http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-wireless-= networks/ >>=20 >>=20 >>=20 >> Abstract: >>=20 >> This document analyses the applicability of Multipath TCP to wireless = access >> networks with overlapping coverage area, and it discusses potential = protocol >> extensions that aim to improve operation in such environments. The = analysis >> attempts to identify use cases, benefits as well as technical and = functional >> obstacles encountered in the current version of the protocol. Based = on this >> analysis, recommendations are made on feature-, signaling- and policy >> extensions that promise to enhance Multipath-TCP's value, versatility = and >> market acceptance in wireless access networks. >>=20 >>=20 >>=20 >>=20 >>=20 >> IMPORTANT COMMENTS: Apart from a variety of recommendations for = research, >> the I-D proposes the following signaling and policy enhancements: >>=20 >>=20 >>=20 >> MP_SELECT option: >>=20 >> The host sends this option to enforce path-selective operation on its = peer. >> The option is generally sent on the subflow to be used for data >> transmission. It may enclose an address id in case it is sent on = another >> subflow, e.g. in break-before-make scenarios before the designated = path >> becomes available. The option permits low-complexity MPTCP receiver >> solutions (Section 4.4) as well as dynamic overhead shedding for = heavily >> loaded servers (Section 4.5). >>=20 >>=20 >>=20 >> AVAIL_ADDR/UNAVAIL_ADDR option(s): >>=20 >> The host sends this option to inform its peer about the >> availability/unavailability status of an interface referred to via an >> address id. The enclosed address-id permits sending the option from = an >> available interface to refer to an unavailable interface. The option = permits >> the peer to swiftly adjust data transmission when the host=92s = interface >> availability changes. There are multiple use cases for this option = (Section >> 3.6, Section 4.4 and Section 4.5). >>=20 >>=20 >>=20 >> DEFER_ADDR option: >>=20 >> The host sends this option to instruct its peer to use a specific = address >> referred to via an address id as the destination for all future = subflows. >> This option is required for transparent-proxy operation (section 5). >>=20 >>=20 >>=20 >> ADD_ADDR option: >>=20 >> The present version of this option should be modified: The option = should >> only provide a mapping between address id and address value without = further >> advice or request for action. When the ADD_ADDRESS option refers to = the >> source address of the packet it is enclosed in, it can omit the = address >> value. The re-interpretation of this option is necessary to support = multiple >> instructions as provided by the options above (and the one below). >>=20 >>=20 >>=20 >> JOIN_ADDR option: >>=20 >> The host sends this option to request subflow creation (via MP_JOIN) = to an >> address referred to via the enclosed address id. Currently, the >> functionality of this option is melted into the ADD_ADDR option. >>=20 >>=20 >>=20 >> DSS insertion policy for bulk transfer: >>=20 >> To reduce receiver complexity, DSS options should be inserted into = all >> packets of a bulk until the first data ACK is received for a packet >> contained in the bulk (Section 3.7). >>=20 >>=20 >>=20 >>=20 >>=20 >> Please take the details from the corresponding sections of the = document. >> Comments are welcome. Thank you. >>=20 >>=20 >>=20 >> Regards, >>=20 >> Georg Hampel >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >>=20 >>=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From georg.hampel@alcatel-lucent.com Wed Jun 29 07:36:24 2011 Return-Path: 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 96CBF21F8634 for ; Wed, 29 Jun 2011 07:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zGvlUBobBUq for ; Wed, 29 Jun 2011 07:36:23 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3B66E21F8633 for ; Wed, 29 Jun 2011 07:36:22 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p5TEaFcw017890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Jun 2011 09:36:15 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5TEaCQA013652 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Jun 2011 09:36:15 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Wed, 29 Jun 2011 09:36:14 -0500 From: "Hampel, K Georg (K Georg)" To: Yoshifumi Nishida Date: Wed, 29 Jun 2011 09:36:12 -0500 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: Acw2RKbhL3HWm0OmT5OmIJx/o60S6gAIqHNA Message-ID: <154773479ED2314980CB638A48FC443484E4B2BC@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 14:36:24 -0000 Hi Yoshifumi, all MP_SELECT combines two functions: 1) enforce path-selective operation on th= e remote host and 2) recommend a specific path the remote host should use f= or data transmissions.=20 The first function MUST be binding. It allows the host to reduce its receiv= e buffer size since it can count on data to arrive on only one path (outsid= e path-reselection windows at least). The second function represents a path recommendation. The remote host may d= isagree with this recommendation. The draft discusses a conflict-resolution= scheme in this case: =20 - If the remote host is not happy with the path proposed by MP_SELECT, it c= an respond with its own MP_SELECT message proposing a new path. - To avoid ping-pong in conflict cases, every host can choose the local int= erface and impose this selection to the peer. (The local interface is gener= ally the source address of the MP_SELECT message unless an explicit ADDRESS= -ID is included as suggested by Alan). This policy resolves conflict within= one MP_SELECT exchange. Regards, Georg -----Original Message----- From: yoshifumi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] On B= ehalf Of Yoshifumi Nishida Sent: Wednesday, June 29, 2011 6:10 AM To: Hampel, K Georg (K Georg) Cc: philip.eardley@bt.com; multipathtcp@ietf.org; Klein, Thierry E (Thierry= ) Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi Georg, Thanks for the summary. Could you elaborate the binding in MP_SELECT? I'm wondering how a peer has a strong control to the other peer. If the other peer disagree with it, what will happen? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/6/28 Hampel, K Georg (K Georg) : > Hi Phil, all, > > > > Below is a summary on the present level of agreement. This summary is not > complete but I hope I captured the essential comments. There seems to be > convergence on some points, others are still open and there are > contradicting opinions on BBM. It may make sense to get as much agreement= as > possible via ML prior to the meeting. Thanks. > > > > Regards, > > Georg > > > > > > MP_SELECT: > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Alan Ford: 'I guess we could adapt MP_PRIO t= o achieve this, by > having another value that means "use me and me alone".=A0 Although I thin= k I > need more convincing that it adds value!" > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Georg Hampel: This would do the job. The "us= e me and me alone" > MUST be binding though. > > > > AVAIL/UNAVAIL_ADDRESS: > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Alan Ford: 'If we were to modify the MP_PRIO= option to take an > Address ID (which is something we've thought about doing before but the u= se > cases were not clear), then you could downgrade one path from another. Th= at > may be sufficient (at least, with tolerant flow control).=A0 Shortcuts of= a > second bit to say "Do not use" or "use exclusively" could also help here.= ' > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Georg Hampel:=A0 MP_PRIO with Address ID cha= nges the semantic > meaning since it refers to an address rather than a path. I'm fine with t= his > as long as everybody is aware of it. We may have to file out the details. > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Joe Touch: "I think the key would be to focu= s on the fact that > these are addresses, and include a brief discussion on the limitations of > the approach - i.e., it works for only directly attached interfaces". Joe > further recommended to cite trigtran work in this context. > > > > DEFER_ADDR: > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Alan Ford: I don't see the point of JOIN_ADD= R and ADD_ADDR > separations, but DEFER_ADDR (or "USE_THIS_ADDR!") is an interesting idea > that I need to think about some more! > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Georg Hampel: USE_THIS_ADDR instead of DEFER= _ADDR is fine with me > and may even be clearer. > > > > ADD_ADDRESS: > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Christoph Paasch: "I don't see a case where = the ADD_ADDR-option > is sent, refering to the packet's source address, because the address-id = of > this source-address has already been provided by the MP_JOIN when > establishing the subflow. > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Georg Hampel: That's right I've overseen thi= s. > > > > JOIN_ADDRESS to be separated from ADD_ADDR: > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Georg Hampel: We still need to separate thes= e two functions to > support DEFER_ADDR (or USE_THIS_ADDR) unless the latter options include t= he > address value explicitly. > > > > Break before make: NOT CLARIFIED!!! > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Georg Hampel: If host undergoes lower-layer = BBM, it should send > RST on the old interface to close state on middleboxes. > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Yoshifumi Nishida: "I think L4 should be con= servative to react on > L2/L3 incidents, so I'm a bit skeptical about sending RST here." > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Olivier Bonaventure: "In the case that you m= entioned, the host > should not send a RST when it looses connectivity. Instead, it should lea= ve > the MPTCP session up, switch to the new address and send an MP_JOIN. Afte= r > that, it can use REMOVE_ADDR to indicate that the old address does not wo= rk > anymore (section 3.4). > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 According to Christoph Paasch lower-layer BB= M should lead to > subflow discontinuation since it is not certain that middleboxes will kee= p > state in case the interface is re-connected. > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Georg Hampel: Christoph's statement means th= at the host must send > RST since it cannot count on its peer to react to FIN. > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 to be continued. > > > > DSS insertion policy for bulk transfer: NEEDS MORE DISCUSSION > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Alan Ford: "An implementation SHOULD send DS= S options that cover > multiple segments multiple times, to reduce the need for unnecessary > buffering at the receiver.=A0 It is RECOMMENDED that a sender repeats the= DSS > option until a DATA ACK for some data covered by this mapping is received= ." > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Georg Hampel: We need this to avoid an addit= ional out-of-order > queue for path-selective operation. > > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Christoph Paasch had longer comments on this= . > > > > > > ________________________________ > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Tuesday, June 28, 2011 3:47 AM > To: Hampel, K Georg (K Georg); multipathtcp@ietf.org > > Cc: Klein, Thierry E (Thierry) > Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the > Applicability of Multipath TCP to Wireless Access Networks > > > > Hi, > > I summarise where I think the discussion (triggered by the email below) h= as > got to. This is just to test whether we have consensus on how to change t= he > protocol draft, so please kick. > > Firstly, the MP-PRIO message is altered to include Address ID - and (I > think) a second flag meaning 'use only this subflow' =A0(not sure discuss= ion > finalised on this point) > > Secondly, the other new msgs (see below) suggested by this draft are not > needed > > Thirdly, add some text something like: "An implementation SHOULD send DSS > options that cover multiple segments multiple times, to reduce the need f= or > unnecessary buffering at the receiver.=A0 It is RECOMMENDED that a sender > repeats the DSS option until a DATA ACK for some data covered by this > mapping is received." > > Also, there may be some extra /amended discussion about content-altering > middleboxes (I couldn't tell whether the discussion concluded on this poi= nt) > > Sorry where i misunderstood > > Thanks > > Phil/ > > > > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org= ] > On Behalf Of Hampel, K Georg (K Georg) > Sent: 16 June 2011 16:03 > To: multipathtcp@ietf.org > Cc: Klein, Thierry E (Thierry) > Subject: [multipathtcp] New I-D: Enhancements to Improve the Applicabilit= y > of Multipath TCP to Wireless Access Networks > > > > All, > > > > We have uploaded a new I-D. > > > > Title: Enhancements to Improve the Applicability of Multipath TCP to > Wireless Access Networks > > > > Authors: Georg Hampel, Thierry Klein > > > > Filename: draft-hampel-mptcp-applicability-wireless-networks-00.txt > > > > URL: > http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-wireless= -networks/ > > > > Abstract: > > This document analyses the applicability of Multipath TCP to wireless acc= ess > networks with overlapping coverage area, and it discusses potential proto= col > extensions that aim to improve operation in such environments.=A0 The ana= lysis > attempts to identify use cases, benefits as well as technical and functio= nal > obstacles encountered in the current version of the protocol.=A0 Based on= this > analysis, recommendations are made on feature-, signaling- and policy > extensions that promise to enhance Multipath-TCP's value, versatility and > market acceptance in wireless access networks. > > > > > > IMPORTANT COMMENTS: Apart from a variety of recommendations for research, > the I-D proposes the following signaling and policy enhancements: > > > > MP_SELECT option: > > The host sends this option to enforce path-selective operation on its pee= r. > The option is generally sent on the subflow to be used for data > transmission. It may enclose an address id in case it is sent on another > subflow, e.g. in break-before-make scenarios before the designated path > becomes available. The option permits low-complexity MPTCP receiver > solutions (Section 4.4) as well as dynamic overhead shedding for heavily > loaded servers (Section 4.5). > > > > AVAIL_ADDR/UNAVAIL_ADDR option(s): > > The host sends this option to inform its peer about the > availability/unavailability status of an interface referred to via an > address id.=A0 The enclosed address-id permits sending the option from an > available interface to refer to an unavailable interface. The option perm= its > the peer to swiftly adjust data transmission when the host's interface > availability changes. There are multiple use cases for this option (Secti= on > 3.6, Section 4.4 and Section 4.5). > > > > DEFER_ADDR option: > > The host sends this option to instruct its peer to use a specific address > referred to via an address id as the destination for all future subflows. > This option is required for transparent-proxy operation (section 5). > > > > ADD_ADDR option: > > The present version of this option should be modified: The option should > only provide a mapping between address id and address value without furth= er > advice or request for action. When the ADD_ADDRESS option refers to the > source address of the packet it is enclosed in, it can omit the address > value. The re-interpretation of this option is necessary to support multi= ple > instructions as provided by the options above (and the one below). > > > > JOIN_ADDR option: > > The host sends this option to request subflow creation (via MP_JOIN) to a= n > address referred to via the enclosed address id. Currently, the > functionality of this option is melted into the ADD_ADDR option. > > > > DSS insertion policy for bulk transfer: > > To reduce receiver complexity, DSS options should be inserted into all > packets of a bulk until the first data ACK is received for a packet > contained in the bulk (Section 3.7). > > > > > > Please take the details from the corresponding sections of the document. > Comments are welcome. Thank you. > > > > Regards, > > Georg Hampel > > > > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > From georg.hampel@alcatel-lucent.com Wed Jun 29 08:09:46 2011 Return-Path: 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 ACDDC9E800C for ; Wed, 29 Jun 2011 08:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZJfk6jMuL2j for ; Wed, 29 Jun 2011 08:09:44 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id A05A921F84CD for ; Wed, 29 Jun 2011 08:09:43 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p5TF9XrM003564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Jun 2011 10:09:34 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5TF9UEJ000854 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Jun 2011 10:09:31 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 29 Jun 2011 10:09:30 -0500 From: "Hampel, K Georg (K Georg)" To: Costin Raiciu , Yoshifumi Nishida Date: Wed, 29 Jun 2011 10:09:28 -0500 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: Acw2Zatx1XMWgbZ9S9GOlekpUZ+MSQABGp8w Message-ID: <154773479ED2314980CB638A48FC443484E4B30C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 15:09:46 -0000 Hi Costin, all, Here is the questionable BBM scenario: HostA having one radio interface homes on network_1 with IP_1 and starts co= nnection via subflow_1 to HostB. Then HostA moves to network_2, discontinues IP_1 and obtains IP_2. After th= at it starts subflow_2. We assume that subflow_1 is still up but without co= nductivity. Then HostA moves back to network_1, discontinues IP_2 and obtains IP_1 agai= n. Alan's point is (if I understand it right) that HostA has no knowledge i= f middleboxes on network_1 still hold state pertaining to subflow_1. Theref= ore, HostA should start a new subflow from IP_1 right away instead of wasti= ng time on pushing data against a closed firewall. Do we agree on this behavior? (Y/N) In case we agree: Since HostA has to start a new subflow after every lower-= layer BBM, it should immediately terminate the old subflow when lower-layer= BBM occurs. In other words: There is no reason to keep the old subflow up = any longer. The old subflow can be terminated via RST (prior to BBM) or via= REMOVE_ADDR (after BBM). Am I missing something? Regards, Georg=20 -----Original Message----- From: Costin Raiciu [mailto:c.raiciu@cs.ucl.ac.uk]=20 Sent: Wednesday, June 29, 2011 10:06 AM To: Yoshifumi Nishida Cc: Hampel, K Georg (K Georg); multipathtcp@ietf.org; Klein, Thierry E (Thi= erry) Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Going further, I would argue that there is no point to make this path prefe= rence binding for the other endhost. I think the other host SHOULD use thi= s information if possible. If this is not possible, and the receving host = feels so strong about path preference, it can always drop the subflow, or s= end congestion marks.=20 Re: BBM. I don't see it as contentious - as Olivier and Yoshifumi mention, = the host should not reset subflows when the interface dies ; it should let = the transport stack time out the corresponding subflow. Re: Christoph's note about middelboxes timing out state: that is also true = for silent flow (e.g. an ssh session not use for a few minutes). It is orth= ogonal to BBM, and if it happens the flow will crash miserably and does tod= ay's SSH, and that;'s that. Cheers, Cosin On 29 Jun 2011, at 06:09, Yoshifumi Nishida wrote: > Hi Georg, >=20 > Thanks for the summary. Could you elaborate the binding in MP_SELECT? > I'm wondering how a peer has a strong control to the other peer. > If the other peer disagree with it, what will happen? >=20 > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp >=20 > 2011/6/28 Hampel, K Georg (K Georg) : >> Hi Phil, all, >>=20 >>=20 >>=20 >> Below is a summary on the present level of agreement. This summary is no= t >> complete but I hope I captured the essential comments. There seems to be >> convergence on some points, others are still open and there are >> contradicting opinions on BBM. It may make sense to get as much agreemen= t as >> possible via ML prior to the meeting. Thanks. >>=20 >>=20 >>=20 >> Regards, >>=20 >> Georg >>=20 >>=20 >>=20 >>=20 >>=20 >> MP_SELECT: >>=20 >> - Alan Ford: 'I guess we could adapt MP_PRIO to achieve this, b= y >> having another value that means "use me and me alone". Although I think= I >> need more convincing that it adds value!" >>=20 >> - Georg Hampel: This would do the job. The "use me and me alone= " >> MUST be binding though. >>=20 >>=20 >>=20 >> AVAIL/UNAVAIL_ADDRESS: >>=20 >> - Alan Ford: 'If we were to modify the MP_PRIO option to take a= n >> Address ID (which is something we've thought about doing before but the = use >> cases were not clear), then you could downgrade one path from another. T= hat >> may be sufficient (at least, with tolerant flow control). Shortcuts of = a >> second bit to say "Do not use" or "use exclusively" could also help here= .' >>=20 >> - Georg Hampel: MP_PRIO with Address ID changes the semantic >> meaning since it refers to an address rather than a path. I'm fine with = this >> as long as everybody is aware of it. We may have to file out the details= . >>=20 >> - Joe Touch: "I think the key would be to focus on the fact tha= t >> these are addresses, and include a brief discussion on the limitations o= f >> the approach - i.e., it works for only directly attached interfaces". Jo= e >> further recommended to cite trigtran work in this context. >>=20 >>=20 >>=20 >> DEFER_ADDR: >>=20 >> - Alan Ford: I don't see the point of JOIN_ADDR and ADD_ADDR >> separations, but DEFER_ADDR (or "USE_THIS_ADDR!") is an interesting idea >> that I need to think about some more! >>=20 >> - Georg Hampel: USE_THIS_ADDR instead of DEFER_ADDR is fine wit= h me >> and may even be clearer. >>=20 >>=20 >>=20 >> ADD_ADDRESS: >>=20 >> - Christoph Paasch: "I don't see a case where the ADD_ADDR-opti= on >> is sent, refering to the packet's source address, because the address-id= of >> this source-address has already been provided by the MP_JOIN when >> establishing the subflow. >>=20 >> - Georg Hampel: That's right I've overseen this. >>=20 >>=20 >>=20 >> JOIN_ADDRESS to be separated from ADD_ADDR: >>=20 >> - Georg Hampel: We still need to separate these two functions t= o >> support DEFER_ADDR (or USE_THIS_ADDR) unless the latter options include = the >> address value explicitly. >>=20 >>=20 >>=20 >> Break before make: NOT CLARIFIED!!! >>=20 >> - Georg Hampel: If host undergoes lower-layer BBM, it should se= nd >> RST on the old interface to close state on middleboxes. >>=20 >> - Yoshifumi Nishida: "I think L4 should be conservative to reac= t on >> L2/L3 incidents, so I'm a bit skeptical about sending RST here." >>=20 >> - Olivier Bonaventure: "In the case that you mentioned, the hos= t >> should not send a RST when it looses connectivity. Instead, it should le= ave >> the MPTCP session up, switch to the new address and send an MP_JOIN. Aft= er >> that, it can use REMOVE_ADDR to indicate that the old address does not w= ork >> anymore (section 3.4). >>=20 >> - According to Christoph Paasch lower-layer BBM should lead to >> subflow discontinuation since it is not certain that middleboxes will ke= ep >> state in case the interface is re-connected. >>=20 >> - Georg Hampel: Christoph's statement means that the host must = send >> RST since it cannot count on its peer to react to FIN. >>=20 >> - to be continued... >>=20 >>=20 >>=20 >> DSS insertion policy for bulk transfer: NEEDS MORE DISCUSSION >>=20 >> - Alan Ford: "An implementation SHOULD send DSS options that co= ver >> multiple segments multiple times, to reduce the need for unnecessary >> buffering at the receiver. It is RECOMMENDED that a sender repeats the = DSS >> option until a DATA ACK for some data covered by this mapping is receive= d." >>=20 >> - Georg Hampel: We need this to avoid an additional out-of-orde= r >> queue for path-selective operation. >>=20 >> - Christoph Paasch had longer comments on this... >>=20 >>=20 >>=20 >>=20 >>=20 >> ________________________________ >>=20 >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >> Sent: Tuesday, June 28, 2011 3:47 AM >> To: Hampel, K Georg (K Georg); multipathtcp@ietf.org >>=20 >> Cc: Klein, Thierry E (Thierry) >> Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the >> Applicability of Multipath TCP to Wireless Access Networks >>=20 >>=20 >>=20 >> Hi, >>=20 >> I summarise where I think the discussion (triggered by the email below) = has >> got to. This is just to test whether we have consensus on how to change = the >> protocol draft, so please kick. >>=20 >> Firstly, the MP-PRIO message is altered to include Address ID - and (I >> think) a second flag meaning 'use only this subflow' (not sure discussi= on >> finalised on this point) >>=20 >> Secondly, the other new msgs (see below) suggested by this draft are not >> needed >>=20 >> Thirdly, add some text something like: "An implementation SHOULD send DS= S >> options that cover multiple segments multiple times, to reduce the need = for >> unnecessary buffering at the receiver. It is RECOMMENDED that a sender >> repeats the DSS option until a DATA ACK for some data covered by this >> mapping is received." >>=20 >> Also, there may be some extra /amended discussion about content-altering >> middleboxes (I couldn't tell whether the discussion concluded on this po= int) >>=20 >> Sorry where i misunderstood >>=20 >> Thanks >>=20 >> Phil/ >>=20 >>=20 >>=20 >> From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.or= g] >> On Behalf Of Hampel, K Georg (K Georg) >> Sent: 16 June 2011 16:03 >> To: multipathtcp@ietf.org >> Cc: Klein, Thierry E (Thierry) >> Subject: [multipathtcp] New I-D: Enhancements to Improve the Applicabili= ty >> of Multipath TCP to Wireless Access Networks >>=20 >>=20 >>=20 >> All, >>=20 >>=20 >>=20 >> We have uploaded a new I-D. >>=20 >>=20 >>=20 >> Title: Enhancements to Improve the Applicability of Multipath TCP to >> Wireless Access Networks >>=20 >>=20 >>=20 >> Authors: Georg Hampel, Thierry Klein >>=20 >>=20 >>=20 >> Filename: draft-hampel-mptcp-applicability-wireless-networks-00.txt >>=20 >>=20 >>=20 >> URL: >> http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-wireles= s-networks/ >>=20 >>=20 >>=20 >> Abstract: >>=20 >> This document analyses the applicability of Multipath TCP to wireless ac= cess >> networks with overlapping coverage area, and it discusses potential prot= ocol >> extensions that aim to improve operation in such environments. The anal= ysis >> attempts to identify use cases, benefits as well as technical and functi= onal >> obstacles encountered in the current version of the protocol. Based on = this >> analysis, recommendations are made on feature-, signaling- and policy >> extensions that promise to enhance Multipath-TCP's value, versatility an= d >> market acceptance in wireless access networks. >>=20 >>=20 >>=20 >>=20 >>=20 >> IMPORTANT COMMENTS: Apart from a variety of recommendations for research= , >> the I-D proposes the following signaling and policy enhancements: >>=20 >>=20 >>=20 >> MP_SELECT option: >>=20 >> The host sends this option to enforce path-selective operation on its pe= er. >> The option is generally sent on the subflow to be used for data >> transmission. It may enclose an address id in case it is sent on another >> subflow, e.g. in break-before-make scenarios before the designated path >> becomes available. The option permits low-complexity MPTCP receiver >> solutions (Section 4.4) as well as dynamic overhead shedding for heavily >> loaded servers (Section 4.5). >>=20 >>=20 >>=20 >> AVAIL_ADDR/UNAVAIL_ADDR option(s): >>=20 >> The host sends this option to inform its peer about the >> availability/unavailability status of an interface referred to via an >> address id. The enclosed address-id permits sending the option from an >> available interface to refer to an unavailable interface. The option per= mits >> the peer to swiftly adjust data transmission when the host's interface >> availability changes. There are multiple use cases for this option (Sect= ion >> 3.6, Section 4.4 and Section 4.5). >>=20 >>=20 >>=20 >> DEFER_ADDR option: >>=20 >> The host sends this option to instruct its peer to use a specific addres= s >> referred to via an address id as the destination for all future subflows= . >> This option is required for transparent-proxy operation (section 5). >>=20 >>=20 >>=20 >> ADD_ADDR option: >>=20 >> The present version of this option should be modified: The option should >> only provide a mapping between address id and address value without furt= her >> advice or request for action. When the ADD_ADDRESS option refers to the >> source address of the packet it is enclosed in, it can omit the address >> value. The re-interpretation of this option is necessary to support mult= iple >> instructions as provided by the options above (and the one below). >>=20 >>=20 >>=20 >> JOIN_ADDR option: >>=20 >> The host sends this option to request subflow creation (via MP_JOIN) to = an >> address referred to via the enclosed address id. Currently, the >> functionality of this option is melted into the ADD_ADDR option. >>=20 >>=20 >>=20 >> DSS insertion policy for bulk transfer: >>=20 >> To reduce receiver complexity, DSS options should be inserted into all >> packets of a bulk until the first data ACK is received for a packet >> contained in the bulk (Section 3.7). >>=20 >>=20 >>=20 >>=20 >>=20 >> Please take the details from the corresponding sections of the document. >> Comments are welcome. Thank you. >>=20 >>=20 >>=20 >> Regards, >>=20 >> Georg Hampel >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >>=20 >>=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From c.raiciu@cs.ucl.ac.uk Wed Jun 29 08:18:19 2011 Return-Path: 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 C1F7021F85AE for ; Wed, 29 Jun 2011 08:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCVb0eP3+Gl9 for ; Wed, 29 Jun 2011 08:18:17 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7082621F85AD for ; Wed, 29 Jun 2011 08:18:17 -0700 (PDT) Received: from [12.176.20.2] (helo=[172.17.165.215]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1QbwWi-000Nud-Hd; Wed, 29 Jun 2011 16:18:06 +0100 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Costin Raiciu In-Reply-To: <154773479ED2314980CB638A48FC443484E4B30C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Date: Wed, 29 Jun 2011 11:18:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443484E4B30C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> To: "Hampel, K Georg (K Georg)" X-Mailer: Apple Mail (2.1081) Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 15:18:19 -0000 Hi, > HostA having one radio interface homes on network_1 with IP_1 and = starts connection via subflow_1 to HostB. >=20 > Then HostA moves to network_2, discontinues IP_1 and obtains IP_2. = After that it starts subflow_2. We assume that subflow_1 is still up but = without conductivity. >=20 > Then HostA moves back to network_1, discontinues IP_2 and obtains IP_1 = again. Alan's point is (if I understand it right) that HostA has no = knowledge if middleboxes on network_1 still hold state pertaining to = subflow_1. Therefore, HostA should start a new subflow from IP_1 right = away instead of wasting time on pushing data against a closed firewall. >=20 > Do we agree on this behavior? (Y/N) No. If host A comes back really quickly, or there is just a temporary = failure of the interface, it is good to keep the subflow up. Also, if = middlebox state has vanished, the host will receive a RST from that = middlebox and the subflow will be killed. So there is no hazard here. >=20 > In case we agree: Since HostA has to start a new subflow after every = lower-layer BBM, it should immediately terminate the old subflow when = lower-layer BBM occurs. In other words: There is no reason to keep the = old subflow up any longer. The old subflow can be terminated via RST = (prior to BBM) or via REMOVE_ADDR (after BBM). I see no real reason for this. Instead of saving bandwidth, it could = have the opposite effect. As Yoshifumi pointed out, the transport stack = should be conservative about reactive to low level status changes. Costin >=20 > Am I missing something? >=20 > Regards, >=20 > Georg=20 >=20 >=20 >=20 > -----Original Message----- > From: Costin Raiciu [mailto:c.raiciu@cs.ucl.ac.uk]=20 > Sent: Wednesday, June 29, 2011 10:06 AM > To: Yoshifumi Nishida > Cc: Hampel, K Georg (K Georg); multipathtcp@ietf.org; Klein, Thierry E = (Thierry) > Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the = Applicability of Multipath TCP to Wireless Access Networks >=20 > Going further, I would argue that there is no point to make this path = preference binding for the other endhost. I think the other host SHOULD = use this information if possible. If this is not possible, and the = receving host feels so strong about path preference, it can always drop = the subflow, or send congestion marks.=20 >=20 > Re: BBM. I don't see it as contentious - as Olivier and Yoshifumi = mention, the host should not reset subflows when the interface dies ; it = should let the transport stack time out the corresponding subflow. > Re: Christoph's note about middelboxes timing out state: that is also = true for silent flow (e.g. an ssh session not use for a few minutes). It = is orthogonal to BBM, and if it happens the flow will crash miserably = and does today's SSH, and that;'s that. >=20 > Cheers, > Cosin >=20 >=20 > On 29 Jun 2011, at 06:09, Yoshifumi Nishida wrote: >=20 >> Hi Georg, >>=20 >> Thanks for the summary. Could you elaborate the binding in MP_SELECT? >> I'm wondering how a peer has a strong control to the other peer. >> If the other peer disagree with it, what will happen? >>=20 >> Thanks, >> -- >> Yoshifumi Nishida >> nishida@sfc.wide.ad.jp >>=20 >> 2011/6/28 Hampel, K Georg (K Georg) = : >>> Hi Phil, all, >>>=20 >>>=20 >>>=20 >>> Below is a summary on the present level of agreement. This summary = is not >>> complete but I hope I captured the essential comments. There seems = to be >>> convergence on some points, others are still open and there are >>> contradicting opinions on BBM. It may make sense to get as much = agreement as >>> possible via ML prior to the meeting. Thanks. >>>=20 >>>=20 >>>=20 >>> Regards, >>>=20 >>> Georg >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> MP_SELECT: >>>=20 >>> - Alan Ford: 'I guess we could adapt MP_PRIO to achieve = this, by >>> having another value that means "use me and me alone". Although I = think I >>> need more convincing that it adds value!" >>>=20 >>> - Georg Hampel: This would do the job. The "use me and me = alone" >>> MUST be binding though. >>>=20 >>>=20 >>>=20 >>> AVAIL/UNAVAIL_ADDRESS: >>>=20 >>> - Alan Ford: 'If we were to modify the MP_PRIO option to = take an >>> Address ID (which is something we've thought about doing before but = the use >>> cases were not clear), then you could downgrade one path from = another. That >>> may be sufficient (at least, with tolerant flow control). Shortcuts = of a >>> second bit to say "Do not use" or "use exclusively" could also help = here.' >>>=20 >>> - Georg Hampel: MP_PRIO with Address ID changes the = semantic >>> meaning since it refers to an address rather than a path. I'm fine = with this >>> as long as everybody is aware of it. We may have to file out the = details. >>>=20 >>> - Joe Touch: "I think the key would be to focus on the fact = that >>> these are addresses, and include a brief discussion on the = limitations of >>> the approach - i.e., it works for only directly attached = interfaces". Joe >>> further recommended to cite trigtran work in this context. >>>=20 >>>=20 >>>=20 >>> DEFER_ADDR: >>>=20 >>> - Alan Ford: I don't see the point of JOIN_ADDR and = ADD_ADDR >>> separations, but DEFER_ADDR (or "USE_THIS_ADDR!") is an interesting = idea >>> that I need to think about some more! >>>=20 >>> - Georg Hampel: USE_THIS_ADDR instead of DEFER_ADDR is fine = with me >>> and may even be clearer. >>>=20 >>>=20 >>>=20 >>> ADD_ADDRESS: >>>=20 >>> - Christoph Paasch: "I don't see a case where the = ADD_ADDR-option >>> is sent, refering to the packet's source address, because the = address-id of >>> this source-address has already been provided by the MP_JOIN when >>> establishing the subflow. >>>=20 >>> - Georg Hampel: That's right I've overseen this. >>>=20 >>>=20 >>>=20 >>> JOIN_ADDRESS to be separated from ADD_ADDR: >>>=20 >>> - Georg Hampel: We still need to separate these two = functions to >>> support DEFER_ADDR (or USE_THIS_ADDR) unless the latter options = include the >>> address value explicitly. >>>=20 >>>=20 >>>=20 >>> Break before make: NOT CLARIFIED!!! >>>=20 >>> - Georg Hampel: If host undergoes lower-layer BBM, it = should send >>> RST on the old interface to close state on middleboxes. >>>=20 >>> - Yoshifumi Nishida: "I think L4 should be conservative to = react on >>> L2/L3 incidents, so I'm a bit skeptical about sending RST here." >>>=20 >>> - Olivier Bonaventure: "In the case that you mentioned, the = host >>> should not send a RST when it looses connectivity. Instead, it = should leave >>> the MPTCP session up, switch to the new address and send an MP_JOIN. = After >>> that, it can use REMOVE_ADDR to indicate that the old address does = not work >>> anymore (section 3.4). >>>=20 >>> - According to Christoph Paasch lower-layer BBM should lead = to >>> subflow discontinuation since it is not certain that middleboxes = will keep >>> state in case the interface is re-connected. >>>=20 >>> - Georg Hampel: Christoph's statement means that the host = must send >>> RST since it cannot count on its peer to react to FIN. >>>=20 >>> - to be continued... >>>=20 >>>=20 >>>=20 >>> DSS insertion policy for bulk transfer: NEEDS MORE DISCUSSION >>>=20 >>> - Alan Ford: "An implementation SHOULD send DSS options = that cover >>> multiple segments multiple times, to reduce the need for unnecessary >>> buffering at the receiver. It is RECOMMENDED that a sender repeats = the DSS >>> option until a DATA ACK for some data covered by this mapping is = received." >>>=20 >>> - Georg Hampel: We need this to avoid an additional = out-of-order >>> queue for path-selective operation. >>>=20 >>> - Christoph Paasch had longer comments on this... >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> ________________________________ >>>=20 >>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >>> Sent: Tuesday, June 28, 2011 3:47 AM >>> To: Hampel, K Georg (K Georg); multipathtcp@ietf.org >>>=20 >>> Cc: Klein, Thierry E (Thierry) >>> Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the >>> Applicability of Multipath TCP to Wireless Access Networks >>>=20 >>>=20 >>>=20 >>> Hi, >>>=20 >>> I summarise where I think the discussion (triggered by the email = below) has >>> got to. This is just to test whether we have consensus on how to = change the >>> protocol draft, so please kick. >>>=20 >>> Firstly, the MP-PRIO message is altered to include Address ID - and = (I >>> think) a second flag meaning 'use only this subflow' (not sure = discussion >>> finalised on this point) >>>=20 >>> Secondly, the other new msgs (see below) suggested by this draft are = not >>> needed >>>=20 >>> Thirdly, add some text something like: "An implementation SHOULD = send DSS >>> options that cover multiple segments multiple times, to reduce the = need for >>> unnecessary buffering at the receiver. It is RECOMMENDED that a = sender >>> repeats the DSS option until a DATA ACK for some data covered by = this >>> mapping is received." >>>=20 >>> Also, there may be some extra /amended discussion about = content-altering >>> middleboxes (I couldn't tell whether the discussion concluded on = this point) >>>=20 >>> Sorry where i misunderstood >>>=20 >>> Thanks >>>=20 >>> Phil/ >>>=20 >>>=20 >>>=20 >>> From: multipathtcp-bounces@ietf.org = [mailto:multipathtcp-bounces@ietf.org] >>> On Behalf Of Hampel, K Georg (K Georg) >>> Sent: 16 June 2011 16:03 >>> To: multipathtcp@ietf.org >>> Cc: Klein, Thierry E (Thierry) >>> Subject: [multipathtcp] New I-D: Enhancements to Improve the = Applicability >>> of Multipath TCP to Wireless Access Networks >>>=20 >>>=20 >>>=20 >>> All, >>>=20 >>>=20 >>>=20 >>> We have uploaded a new I-D. >>>=20 >>>=20 >>>=20 >>> Title: Enhancements to Improve the Applicability of Multipath TCP to >>> Wireless Access Networks >>>=20 >>>=20 >>>=20 >>> Authors: Georg Hampel, Thierry Klein >>>=20 >>>=20 >>>=20 >>> Filename: draft-hampel-mptcp-applicability-wireless-networks-00.txt >>>=20 >>>=20 >>>=20 >>> URL: >>> = http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-wireless-= networks/ >>>=20 >>>=20 >>>=20 >>> Abstract: >>>=20 >>> This document analyses the applicability of Multipath TCP to = wireless access >>> networks with overlapping coverage area, and it discusses potential = protocol >>> extensions that aim to improve operation in such environments. The = analysis >>> attempts to identify use cases, benefits as well as technical and = functional >>> obstacles encountered in the current version of the protocol. Based = on this >>> analysis, recommendations are made on feature-, signaling- and = policy >>> extensions that promise to enhance Multipath-TCP's value, = versatility and >>> market acceptance in wireless access networks. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> IMPORTANT COMMENTS: Apart from a variety of recommendations for = research, >>> the I-D proposes the following signaling and policy enhancements: >>>=20 >>>=20 >>>=20 >>> MP_SELECT option: >>>=20 >>> The host sends this option to enforce path-selective operation on = its peer. >>> The option is generally sent on the subflow to be used for data >>> transmission. It may enclose an address id in case it is sent on = another >>> subflow, e.g. in break-before-make scenarios before the designated = path >>> becomes available. The option permits low-complexity MPTCP receiver >>> solutions (Section 4.4) as well as dynamic overhead shedding for = heavily >>> loaded servers (Section 4.5). >>>=20 >>>=20 >>>=20 >>> AVAIL_ADDR/UNAVAIL_ADDR option(s): >>>=20 >>> The host sends this option to inform its peer about the >>> availability/unavailability status of an interface referred to via = an >>> address id. The enclosed address-id permits sending the option from = an >>> available interface to refer to an unavailable interface. The option = permits >>> the peer to swiftly adjust data transmission when the host's = interface >>> availability changes. There are multiple use cases for this option = (Section >>> 3.6, Section 4.4 and Section 4.5). >>>=20 >>>=20 >>>=20 >>> DEFER_ADDR option: >>>=20 >>> The host sends this option to instruct its peer to use a specific = address >>> referred to via an address id as the destination for all future = subflows. >>> This option is required for transparent-proxy operation (section 5). >>>=20 >>>=20 >>>=20 >>> ADD_ADDR option: >>>=20 >>> The present version of this option should be modified: The option = should >>> only provide a mapping between address id and address value without = further >>> advice or request for action. When the ADD_ADDRESS option refers to = the >>> source address of the packet it is enclosed in, it can omit the = address >>> value. The re-interpretation of this option is necessary to support = multiple >>> instructions as provided by the options above (and the one below). >>>=20 >>>=20 >>>=20 >>> JOIN_ADDR option: >>>=20 >>> The host sends this option to request subflow creation (via MP_JOIN) = to an >>> address referred to via the enclosed address id. Currently, the >>> functionality of this option is melted into the ADD_ADDR option. >>>=20 >>>=20 >>>=20 >>> DSS insertion policy for bulk transfer: >>>=20 >>> To reduce receiver complexity, DSS options should be inserted into = all >>> packets of a bulk until the first data ACK is received for a packet >>> contained in the bulk (Section 3.7). >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Please take the details from the corresponding sections of the = document. >>> Comments are welcome. Thank you. >>>=20 >>>=20 >>>=20 >>> Regards, >>>=20 >>> Georg Hampel >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>=20 >>>=20 >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >=20 From georg.hampel@alcatel-lucent.com Wed Jun 29 10:51:30 2011 Return-Path: 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 6A7E69E8052 for ; Wed, 29 Jun 2011 10:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LydlV2Q-ATEu for ; Wed, 29 Jun 2011 10:51:28 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 963BC9E804F for ; Wed, 29 Jun 2011 10:51:25 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p5THpHdW023112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Jun 2011 12:51:18 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5THpCLO001020 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Jun 2011 12:51:16 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 29 Jun 2011 12:51:16 -0500 From: "Hampel, K Georg (K Georg)" To: Costin Raiciu Date: Wed, 29 Jun 2011 12:51:14 -0500 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: Acw2b8Yge/fh5nFOQf+2YVJ7ayb5HAAFTH8g Message-ID: <154773479ED2314980CB638A48FC443484EBF555@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443484E4B30C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 17:51:30 -0000 Hi Costin, all, Okay. Unless anybody disagrees BBM can be considered resolved. Thanks. Georg -----Original Message----- From: Costin Raiciu [mailto:c.raiciu@cs.ucl.ac.uk] Sent: Wednesday, June 29, 2011 11:18 AM To: Hampel, K Georg (K Georg) Cc: Yoshifumi Nishida; multipathtcp@ietf.org; Klein, Thierry E (Thierry) Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi, > HostA having one radio interface homes on network_1 with IP_1 and starts = connection via subflow_1 to HostB. > > Then HostA moves to network_2, discontinues IP_1 and obtains IP_2. After = that it starts subflow_2. We assume that subflow_1 is still up but without = conductivity. > > Then HostA moves back to network_1, discontinues IP_2 and obtains IP_1 ag= ain. Alan's point is (if I understand it right) that HostA has no knowledge= if middleboxes on network_1 still hold state pertaining to subflow_1. Ther= efore, HostA should start a new subflow from IP_1 right away instead of was= ting time on pushing data against a closed firewall. > > Do we agree on this behavior? (Y/N) No. If host A comes back really quickly, or there is just a temporary failu= re of the interface, it is good to keep the subflow up. Also, if middlebox = state has vanished, the host will receive a RST from that middlebox and the= subflow will be killed. So there is no hazard here. > > In case we agree: Since HostA has to start a new subflow after every lowe= r-layer BBM, it should immediately terminate the old subflow when lower-lay= er BBM occurs. In other words: There is no reason to keep the old subflow u= p any longer. The old subflow can be terminated via RST (prior to BBM) or v= ia REMOVE_ADDR (after BBM). I see no real reason for this. Instead of saving bandwidth, it could have t= he opposite effect. As Yoshifumi pointed out, the transport stack should be= conservative about reactive to low level status changes. Costin > > Am I missing something? > > Regards, > > Georg > > > > -----Original Message----- > From: Costin Raiciu [mailto:c.raiciu@cs.ucl.ac.uk] > Sent: Wednesday, June 29, 2011 10:06 AM > To: Yoshifumi Nishida > Cc: Hampel, K Georg (K Georg); multipathtcp@ietf.org; Klein, Thierry E (T= hierry) > Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicab= ility of Multipath TCP to Wireless Access Networks > > Going further, I would argue that there is no point to make this path pre= ference binding for the other endhost. I think the other host SHOULD use t= his information if possible. If this is not possible, and the receving hos= t feels so strong about path preference, it can always drop the subflow, or= send congestion marks. > > Re: BBM. I don't see it as contentious - as Olivier and Yoshifumi mention= , the host should not reset subflows when the interface dies ; it should le= t the transport stack time out the corresponding subflow. > Re: Christoph's note about middelboxes timing out state: that is also tru= e for silent flow (e.g. an ssh session not use for a few minutes). It is or= thogonal to BBM, and if it happens the flow will crash miserably and does t= oday's SSH, and that;'s that. > > Cheers, > Cosin > > > On 29 Jun 2011, at 06:09, Yoshifumi Nishida wrote: > >> Hi Georg, >> >> Thanks for the summary. Could you elaborate the binding in MP_SELECT? >> I'm wondering how a peer has a strong control to the other peer. >> If the other peer disagree with it, what will happen? >> >> Thanks, >> -- >> Yoshifumi Nishida >> nishida@sfc.wide.ad.jp >> >> 2011/6/28 Hampel, K Georg (K Georg) : >>> Hi Phil, all, >>> >>> >>> >>> Below is a summary on the present level of agreement. This summary is n= ot >>> complete but I hope I captured the essential comments. There seems to b= e >>> convergence on some points, others are still open and there are >>> contradicting opinions on BBM. It may make sense to get as much agreeme= nt as >>> possible via ML prior to the meeting. Thanks. >>> >>> >>> >>> Regards, >>> >>> Georg >>> >>> >>> >>> >>> >>> MP_SELECT: >>> >>> - Alan Ford: 'I guess we could adapt MP_PRIO to achieve this, = by >>> having another value that means "use me and me alone". Although I thin= k I >>> need more convincing that it adds value!" >>> >>> - Georg Hampel: This would do the job. The "use me and me alon= e" >>> MUST be binding though. >>> >>> >>> >>> AVAIL/UNAVAIL_ADDRESS: >>> >>> - Alan Ford: 'If we were to modify the MP_PRIO option to take = an >>> Address ID (which is something we've thought about doing before but the= use >>> cases were not clear), then you could downgrade one path from another. = That >>> may be sufficient (at least, with tolerant flow control). Shortcuts of= a >>> second bit to say "Do not use" or "use exclusively" could also help her= e.' >>> >>> - Georg Hampel: MP_PRIO with Address ID changes the semantic >>> meaning since it refers to an address rather than a path. I'm fine with= this >>> as long as everybody is aware of it. We may have to file out the detail= s. >>> >>> - Joe Touch: "I think the key would be to focus on the fact th= at >>> these are addresses, and include a brief discussion on the limitations = of >>> the approach - i.e., it works for only directly attached interfaces". J= oe >>> further recommended to cite trigtran work in this context. >>> >>> >>> >>> DEFER_ADDR: >>> >>> - Alan Ford: I don't see the point of JOIN_ADDR and ADD_ADDR >>> separations, but DEFER_ADDR (or "USE_THIS_ADDR!") is an interesting ide= a >>> that I need to think about some more! >>> >>> - Georg Hampel: USE_THIS_ADDR instead of DEFER_ADDR is fine wi= th me >>> and may even be clearer. >>> >>> >>> >>> ADD_ADDRESS: >>> >>> - Christoph Paasch: "I don't see a case where the ADD_ADDR-opt= ion >>> is sent, refering to the packet's source address, because the address-i= d of >>> this source-address has already been provided by the MP_JOIN when >>> establishing the subflow. >>> >>> - Georg Hampel: That's right I've overseen this. >>> >>> >>> >>> JOIN_ADDRESS to be separated from ADD_ADDR: >>> >>> - Georg Hampel: We still need to separate these two functions = to >>> support DEFER_ADDR (or USE_THIS_ADDR) unless the latter options include= the >>> address value explicitly. >>> >>> >>> >>> Break before make: NOT CLARIFIED!!! >>> >>> - Georg Hampel: If host undergoes lower-layer BBM, it should s= end >>> RST on the old interface to close state on middleboxes. >>> >>> - Yoshifumi Nishida: "I think L4 should be conservative to rea= ct on >>> L2/L3 incidents, so I'm a bit skeptical about sending RST here." >>> >>> - Olivier Bonaventure: "In the case that you mentioned, the ho= st >>> should not send a RST when it looses connectivity. Instead, it should l= eave >>> the MPTCP session up, switch to the new address and send an MP_JOIN. Af= ter >>> that, it can use REMOVE_ADDR to indicate that the old address does not = work >>> anymore (section 3.4). >>> >>> - According to Christoph Paasch lower-layer BBM should lead to >>> subflow discontinuation since it is not certain that middleboxes will k= eep >>> state in case the interface is re-connected. >>> >>> - Georg Hampel: Christoph's statement means that the host must= send >>> RST since it cannot count on its peer to react to FIN. >>> >>> - to be continued... >>> >>> >>> >>> DSS insertion policy for bulk transfer: NEEDS MORE DISCUSSION >>> >>> - Alan Ford: "An implementation SHOULD send DSS options that c= over >>> multiple segments multiple times, to reduce the need for unnecessary >>> buffering at the receiver. It is RECOMMENDED that a sender repeats the= DSS >>> option until a DATA ACK for some data covered by this mapping is receiv= ed." >>> >>> - Georg Hampel: We need this to avoid an additional out-of-ord= er >>> queue for path-selective operation. >>> >>> - Christoph Paasch had longer comments on this... >>> >>> >>> >>> >>> >>> ________________________________ >>> >>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >>> Sent: Tuesday, June 28, 2011 3:47 AM >>> To: Hampel, K Georg (K Georg); multipathtcp@ietf.org >>> >>> Cc: Klein, Thierry E (Thierry) >>> Subject: RE: [multipathtcp] New I-D: Enhancements to Improve the >>> Applicability of Multipath TCP to Wireless Access Networks >>> >>> >>> >>> Hi, >>> >>> I summarise where I think the discussion (triggered by the email below)= has >>> got to. This is just to test whether we have consensus on how to change= the >>> protocol draft, so please kick. >>> >>> Firstly, the MP-PRIO message is altered to include Address ID - and (I >>> think) a second flag meaning 'use only this subflow' (not sure discuss= ion >>> finalised on this point) >>> >>> Secondly, the other new msgs (see below) suggested by this draft are no= t >>> needed >>> >>> Thirdly, add some text something like: "An implementation SHOULD send D= SS >>> options that cover multiple segments multiple times, to reduce the need= for >>> unnecessary buffering at the receiver. It is RECOMMENDED that a sender >>> repeats the DSS option until a DATA ACK for some data covered by this >>> mapping is received." >>> >>> Also, there may be some extra /amended discussion about content-alterin= g >>> middleboxes (I couldn't tell whether the discussion concluded on this p= oint) >>> >>> Sorry where i misunderstood >>> >>> Thanks >>> >>> Phil/ >>> >>> >>> >>> From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.o= rg] >>> On Behalf Of Hampel, K Georg (K Georg) >>> Sent: 16 June 2011 16:03 >>> To: multipathtcp@ietf.org >>> Cc: Klein, Thierry E (Thierry) >>> Subject: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity >>> of Multipath TCP to Wireless Access Networks >>> >>> >>> >>> All, >>> >>> >>> >>> We have uploaded a new I-D. >>> >>> >>> >>> Title: Enhancements to Improve the Applicability of Multipath TCP to >>> Wireless Access Networks >>> >>> >>> >>> Authors: Georg Hampel, Thierry Klein >>> >>> >>> >>> Filename: draft-hampel-mptcp-applicability-wireless-networks-00.txt >>> >>> >>> >>> URL: >>> http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-wirele= ss-networks/ >>> >>> >>> >>> Abstract: >>> >>> This document analyses the applicability of Multipath TCP to wireless a= ccess >>> networks with overlapping coverage area, and it discusses potential pro= tocol >>> extensions that aim to improve operation in such environments. The ana= lysis >>> attempts to identify use cases, benefits as well as technical and funct= ional >>> obstacles encountered in the current version of the protocol. Based on= this >>> analysis, recommendations are made on feature-, signaling- and policy >>> extensions that promise to enhance Multipath-TCP's value, versatility a= nd >>> market acceptance in wireless access networks. >>> >>> >>> >>> >>> >>> IMPORTANT COMMENTS: Apart from a variety of recommendations for researc= h, >>> the I-D proposes the following signaling and policy enhancements: >>> >>> >>> >>> MP_SELECT option: >>> >>> The host sends this option to enforce path-selective operation on its p= eer. >>> The option is generally sent on the subflow to be used for data >>> transmission. It may enclose an address id in case it is sent on anothe= r >>> subflow, e.g. in break-before-make scenarios before the designated path >>> becomes available. The option permits low-complexity MPTCP receiver >>> solutions (Section 4.4) as well as dynamic overhead shedding for heavil= y >>> loaded servers (Section 4.5). >>> >>> >>> >>> AVAIL_ADDR/UNAVAIL_ADDR option(s): >>> >>> The host sends this option to inform its peer about the >>> availability/unavailability status of an interface referred to via an >>> address id. The enclosed address-id permits sending the option from an >>> available interface to refer to an unavailable interface. The option pe= rmits >>> the peer to swiftly adjust data transmission when the host's interface >>> availability changes. There are multiple use cases for this option (Sec= tion >>> 3.6, Section 4.4 and Section 4.5). >>> >>> >>> >>> DEFER_ADDR option: >>> >>> The host sends this option to instruct its peer to use a specific addre= ss >>> referred to via an address id as the destination for all future subflow= s. >>> This option is required for transparent-proxy operation (section 5). >>> >>> >>> >>> ADD_ADDR option: >>> >>> The present version of this option should be modified: The option shoul= d >>> only provide a mapping between address id and address value without fur= ther >>> advice or request for action. When the ADD_ADDRESS option refers to the >>> source address of the packet it is enclosed in, it can omit the address >>> value. The re-interpretation of this option is necessary to support mul= tiple >>> instructions as provided by the options above (and the one below). >>> >>> >>> >>> JOIN_ADDR option: >>> >>> The host sends this option to request subflow creation (via MP_JOIN) to= an >>> address referred to via the enclosed address id. Currently, the >>> functionality of this option is melted into the ADD_ADDR option. >>> >>> >>> >>> DSS insertion policy for bulk transfer: >>> >>> To reduce receiver complexity, DSS options should be inserted into all >>> packets of a bulk until the first data ACK is received for a packet >>> contained in the bulk (Section 3.7). >>> >>> >>> >>> >>> >>> Please take the details from the corresponding sections of the document= . >>> Comments are welcome. Thank you. >>> >>> >>> >>> Regards, >>> >>> Georg Hampel >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > From georg.hampel@alcatel-lucent.com Wed Jun 29 17:52:30 2011 Return-Path: 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 5B00411E8072 for ; Wed, 29 Jun 2011 17:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4DzGFcuyqJg for ; Wed, 29 Jun 2011 17:52:28 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2680B11E80D0 for ; Wed, 29 Jun 2011 17:52:28 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p5U0qN5f011569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Jun 2011 19:52:23 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5U0qNjp021232 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Jun 2011 19:52:23 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Wed, 29 Jun 2011 19:52:23 -0500 From: "Hampel, K Georg (K Georg)" To: "Hampel, K Georg (K Georg)" , "philip.eardley@bt.com" , "multipathtcp@ietf.org" Date: Wed, 29 Jun 2011 19:52:18 -0500 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: AcwsNoAEwA+vzYT/SF6zM7ztidT2sgJLwJ5AABvqi2AAOqZgAA== Message-ID: <154773479ED2314980CB638A48FC443484EBF71E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: <154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC443484EBF71EUSNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 00:52:30 -0000 --_000_154773479ED2314980CB638A48FC443484EBF71EUSNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I'm proposing to revise the MP_PRIO option as outlined below. The revised v= ersion tries to accommodate the issues discussed recently. Please comment. Regards, Georg =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MP_PRIO sent by Host_A to Host_B contains the following fields: Path =3D (ADDR-ID-A, ADDR-ID-B), where ADDR-ID-A: one of Host_A's addresses; value 255 =3D all; ADDR-ID-B: one of Host_B's addresses; value 255 =3D all; B-flag: (use/don't use) path contained in this option S-flag: (use only one path/use any number of paths) Operation: - Host_A can refer to unavailable paths via available paths due to the expl= icit use of address-ids. This also permits sending an MP_PRIO option redund= antly on multiple paths. - Host_A can refer to a specific interface, e.g. IP_A, by selecting all pat= hs that terminate at this interface, i.e. path =3D (IP_A, all). - Through consecutive MP_PRIO messages, Host_A can specify (and update) the= subset of paths it wants Host_B to consider for data transmission. - Host_B is not bound to use this subset of paths for data transmission. Ho= wever, if a certain interface of Host_A is not contained in any of the path= s of this subset, Host_B should consider this interface unavailable and not= use any of the corresponding paths for data transmission. - The S-flag setting "use only one path" is binding. This path can be selec= ted by Host_B subject to the same constraints as mentioned in the prior bul= let. When an MP_PRIO option arrives, path-re-selection should always occur = AFTER the B-flag- and path-fields of the MP_PRIO option have been evaluated= , since they may change the subset of recommended paths. - If multiple MP_PRIO options are contained in one TCP options header, they= should be evaluated in the order they appear in the header. - There is no explicit confirmation of MP_PRIO. Host_A can implicitly deriv= e MP_PRIO's delivery from acks and/or packets arriving from Host B. Use cases/examples: 1. Set [IP_A, IP_B] as backup path: MP_PRIO: path =3D [IP_A, IP_B], B =3D(don't use), S =3D(use any number) 2. IP_A has become unavailable: MP_PRIO: path =3D [IP_A, all], B =3D(don't use), S =3D(use any number) 3. IP_A is available again: MP_PRIO: path=3D[IP_A, all], B =3D(use), S =3D(use any number) 4. Use only one path, doesn't matter which one: MP_PRIO: path=3D[all, all], B =3D(use), S =3D(use only one path) 5. Use only one path among [IP_A, IP_B] and [IP_A', IP_B']: Add 2 MP_PRIOs into header: MP_PRIO: path =3D [IP_A, IP_B], B =3D(use), S =3D(either setting) MP_PRIO: path =3D [IP_A', IP_B'], B =3D(use), S =3D(use only one path) 6. Switch one selected path from [IP_A, IP_B] to [IP_A', IP_B']: Add 2 MP_PRIOs into header: MP_PRIO: [IP_A, IP_B], B =3D (don't use), S =3D (either setting) MP_PRIO: [IP_A', IP_B'], B =3D (use), S =3D (use only one path) 7. Switch one path from interface IP_A to IP_A': Add 2 MP_PRIOs into header: MP_PRIO: [IP_A, all], B =3D (don't use), S =3D (either setting) MP_PRIO: [IP_A', all], B =3D (use), S =3D (use only one path) --_000_154773479ED2314980CB638A48FC443484EBF71EUSNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I’m proposing to revise the MP_PRIO option as outlined below.= The revised version tries to accommodate the issues discussed recently.

 

Please comment.

Regards,

Georg

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

MP_PRIO sent by Host_A to Host_B contains the following fields:

 

Path =3D (ADDR-ID-A, ADDR-ID-B), where

ADDR-ID-A: one of Host_A’s addresses; valu= e 255 =3D all;

ADDR-ID-B: one of Host_B’s addresses; valu= e 255 =3D all;

B-flag: (use/don’t use) path contained in this option

S-flag: (use only one path/use any number of paths)

 

 

Operation:

- Host_A can refer to unavailable paths via available paths due to = the explicit use of address-ids. This also permits sending an MP_PRIO option redundantly= on multiple paths.

 

- Host_A can refer to a specific interface, e.g. IP_A, by selecting= all paths that terminate at this interface, i.e. path =3D (IP_A, all).

 

- Through consecutive MP_PRIO messages, Host_A can specify (and upd= ate) the subset of paths it wants Host_B to consider for data transmission.=

 

- Host_B is not bound to use this subset of paths for data transmission. However, if a certain interface of Host_A is not contained in= any of the paths of this subset, Host_B should consider this interface unavaila= ble and not use any of the corresponding paths for data transmission.

 

- The S-flag setting “use only one path” is binding. Th= is path can be selected by Host_B subject to the same constraints as mentioned in the prio= r bullet. When an MP_PRIO option arrives, path-re-selection should always occ= ur AFTER the B-flag- and path-fields of the MP_PRIO option have been evaluated, sinc= e they may change the subset of recommended paths.

 

- If multiple MP_PRIO options are contained in one TCP options head= er, they should be evaluated in the order they appear in the header.=

 

- There is no explicit confirmation of MP_PRIO. Host_A can implicit= ly derive MP_PRIO’s delivery from acks and/or packets arriving from Host= B.

 

 

Use cases/examples:

 

1. Set [IP_A, IP_B] as backup path:

MP_PRIO: path =3D [IP_A, IP_B], B =3D(don’t use), S =3D(use a= ny number)

 

2. IP_A has become unavailable:

MP_PRIO: path =3D [IP_A, all], B =3D(don’t use), S =3D(use an= y number)

 

3. IP_A is available again:

MP_PRIO: path=3D[IP_A, all], B =3D(use), S =3D(use any number)=

 

4. Use only one path, doesn’t matter which one:

MP_PRIO: path=3D[all, all], B =3D(use), S =3D(use only one path)

 

5. Use only one path among [IP_A, IP_B] and [IP_A’, IP_B̵= 7;]:

Add 2 MP_PRIOs into header:

MP_PRIO: path =3D [IP_A, IP_B], B =3D(use), S =3D(either setting)

MP_PRIO: path =3D [IP_A’, IP_B’], B =3D(use), S =3D(use= only one path)

 

 

6. Switch one selected path from [IP_A, IP_B] to [IP_A’, IP_B= ’]:

Add 2 MP_PRIOs into header:

MP_PRIO: [IP_A, IP_B], B =3D (don’t use), S =3D (either setti= ng)

MP_PRIO: [IP_A’, IP_B’], B =3D (use), S =3D (use only o= ne path)

 

 

7. Switch one path from interface IP_A to IP_A’:

Add 2 MP_PRIOs into header:

MP_PRIO: [IP_A, all], B =3D (don’t use), S =3D (either settin= g)

MP_PRIO: [IP_A’, all], B =3D (use), S =3D (use only one path)=

 

 

--_000_154773479ED2314980CB638A48FC443484EBF71EUSNAVSXCHMBSA2n_-- From yoshifumi.nishida@gmail.com Thu Jun 30 03:04:00 2011 Return-Path: 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 AFE5A21F87E7 for ; Thu, 30 Jun 2011 03:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dp8J0vslRv1q for ; Thu, 30 Jun 2011 03:03:59 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B419E21F87E5 for ; Thu, 30 Jun 2011 03:03:59 -0700 (PDT) Received: by iwn39 with SMTP id 39so2301002iwn.31 for ; Thu, 30 Jun 2011 03:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cUbk3OkuJF5oxr7Km89FF5ESLM0pgNIVxz6q2B1C/q8=; b=Uohtsa5huk3IuV2RmKfU6sh3XHf26cESdvgW2Y5USqp7dGj+WesS5nLpxsQZm3FwHU jlEwKmRJOxkcWKqQ4x7hIPj4WFKODp85QCaXVc05Auf+glkj0HPH91HbMNgf/x94NMMz JlivG1FyuKxRtPv8idSnT9EVJBNBNE/7mH+6o= MIME-Version: 1.0 Received: by 10.231.60.73 with SMTP id o9mr1639363ibh.33.1309428239171; Thu, 30 Jun 2011 03:03:59 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.199.12 with HTTP; Thu, 30 Jun 2011 03:03:59 -0700 (PDT) In-Reply-To: <154773479ED2314980CB638A48FC443484EBF71E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443484EBF71E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Date: Thu, 30 Jun 2011 03:03:59 -0700 X-Google-Sender-Auth: _yYWOh28s-HxqbzaaoH1_aBQvlU Message-ID: From: Yoshifumi Nishida To: "Hampel, K Georg (K Georg)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 10:04:00 -0000 Hi Georg, In this proposal, if we specify a non-existing sub-connection and set "use only this path", what will happen? Also, I'm still wondering how to solve binding loop where both ends have conflicted policies. (sorry i couldn't parse your previous e-mail.) Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/6/29 Hampel, K Georg (K Georg) : > Hi all, > > > > I=92m proposing to revise the MP_PRIO option as outlined below. The revis= ed > version tries to accommodate the issues discussed recently. > > > > Please comment. > > Regards, > > Georg > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > MP_PRIO sent by Host_A to Host_B contains the following fields: > > > > Path =3D (ADDR-ID-A, ADDR-ID-B), where > > ADDR-ID-A: one of Host_A=92s addresses; value 255 =3D all; > > ADDR-ID-B: one of Host_B=92s addresses; value 255 =3D all; > > B-flag: (use/don=92t use) path contained in this option > > S-flag: (use only one path/use any number of paths) > > > > > > Operation: > > - Host_A can refer to unavailable paths via available paths due to the > explicit use of address-ids. This also permits sending an MP_PRIO option > redundantly on multiple paths. > > > > - Host_A can refer to a specific interface, e.g. IP_A, by selecting all > paths that terminate at this interface, i.e. path =3D (IP_A, all). > > > > - Through consecutive MP_PRIO messages, Host_A can specify (and update) t= he > subset of paths it wants Host_B to consider for data transmission. > > > > - Host_B is not bound to use this subset of paths for data transmission. > However, if a certain interface of Host_A is not contained in any of the > paths of this subset, Host_B should consider this interface unavailable a= nd > not use any of the corresponding paths for data transmission. > > > > - The S-flag setting =93use only one path=94 is binding. This path can be > selected by Host_B subject to the same constraints as mentioned in the pr= ior > bullet. When an MP_PRIO option arrives, path-re-selection should always > occur AFTER the B-flag- and path-fields of the MP_PRIO option have been > evaluated, since they may change the subset of recommended paths. > > > > - If multiple MP_PRIO options are contained in one TCP options header, th= ey > should be evaluated in the order they appear in the header. > > > > - There is no explicit confirmation of MP_PRIO. Host_A can implicitly der= ive > MP_PRIO=92s delivery from acks and/or packets arriving from Host B. > > > > > > Use cases/examples: > > > > 1. Set [IP_A, IP_B] as backup path: > > MP_PRIO: path =3D [IP_A, IP_B], B =3D(don=92t use), S =3D(use any number) > > > > 2. IP_A has become unavailable: > > MP_PRIO: path =3D [IP_A, all], B =3D(don=92t use), S =3D(use any number) > > > > 3. IP_A is available again: > > MP_PRIO: path=3D[IP_A, all], B =3D(use), S =3D(use any number) > > > > 4. Use only one path, doesn=92t matter which one: > > MP_PRIO: path=3D[all, all], B =3D(use), S =3D(use only one path) > > > > 5. Use only one path among [IP_A, IP_B] and [IP_A=92, IP_B=92]: > > Add 2 MP_PRIOs into header: > > MP_PRIO: path =3D [IP_A, IP_B], B =3D(use), S =3D(either setting) > > MP_PRIO: path =3D [IP_A=92, IP_B=92], B =3D(use), S =3D(use only one path= ) > > > > > > 6. Switch one selected path from [IP_A, IP_B] to [IP_A=92, IP_B=92]: > > Add 2 MP_PRIOs into header: > > MP_PRIO: [IP_A, IP_B], B =3D (don=92t use), S =3D (either setting) > > MP_PRIO: [IP_A=92, IP_B=92], B =3D (use), S =3D (use only one path) > > > > > > 7. Switch one path from interface IP_A to IP_A=92: > > Add 2 MP_PRIOs into header: > > MP_PRIO: [IP_A, all], B =3D (don=92t use), S =3D (either setting) > > MP_PRIO: [IP_A=92, all], B =3D (use), S =3D (use only one path) > > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > From georg.hampel@alcatel-lucent.com Thu Jun 30 06:42:45 2011 Return-Path: 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 2D9F611E80BF for ; Thu, 30 Jun 2011 06:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pjdD4ISvq-8 for ; Thu, 30 Jun 2011 06:42:44 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5D43211E8123 for ; Thu, 30 Jun 2011 06:42:44 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p5UDgcgR005591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Jun 2011 08:42:38 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5UDgZtQ023548 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 30 Jun 2011 08:42:37 -0500 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 30 Jun 2011 08:42:26 -0500 From: "Hampel, K Georg (K Georg)" To: Yoshifumi Nishida Date: Thu, 30 Jun 2011 08:42:25 -0500 Thread-Topic: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks Thread-Index: Acw3DQkup4Kv+9R8Rmer28t48EE48wAG39Zg Message-ID: <154773479ED2314980CB638A48FC443484EBF7EA@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <154773479ED2314980CB638A48FC443484EBF71E@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "multipathtcp@ietf.org" , "Klein, Thierry E \(Thierry\)" Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless Access Networks X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 13:42:45 -0000 Hi Yoshifumi, There is no "use only THIS path". Instead, there is "use only ONE path". Wh= ile this command is binding, it does not specify the path itself. Host_B ca= n select this path from all available paths while honoring the associated u= se/don't use recommendations sent by Host_A.=20 (For a simplified receiver on Host_A it is important to restrict data deliv= ery to one path. Path selection is of lower priority and subject to the sam= e constraints as in full-fledged MPTCP.) "Use/Don't use" recommendations for non-existent paths should have no effec= t. Conflicting interests:=20 "Use/Don't use" flags are primarily recommendations which SHOULD be honored= (this is the same as for the present MP_PRIO). Host_B may overwrite this S= HOULD due to economical reasons, for instance. If a certain interface on Host_A is not part of any recommended path, Host_= B can assume that it is not up or has very poor local link quality. In this= case, Host_B SHOULD not use the associated paths for technical reasons.=20 We COULD replace SHOULD with MUST in this latter case. However, if a certai= n interface is completely inaccessible for extended time, Host_A can simply= tear down the associated paths. Georg=20 -----Original Message----- From: yoshifumi.nishida@gmail.com [mailto:yoshifumi.nishida@gmail.com] On B= ehalf Of Yoshifumi Nishida Sent: Thursday, June 30, 2011 6:04 AM To: Hampel, K Georg (K Georg) Cc: philip.eardley@bt.com; multipathtcp@ietf.org; Klein, Thierry E (Thierry= ) Subject: Re: [multipathtcp] New I-D: Enhancements to Improve the Applicabil= ity of Multipath TCP to Wireless Access Networks Hi Georg, In this proposal, if we specify a non-existing sub-connection and set "use only this path", what will happen? Also, I'm still wondering how to solve binding loop where both ends have conflicted policies. (sorry i couldn't parse your previous e-mail.) Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/6/29 Hampel, K Georg (K Georg) : > Hi all, > > > > I'm proposing to revise the MP_PRIO option as outlined below. The revised > version tries to accommodate the issues discussed recently. > > > > Please comment. > > Regards, > > Georg > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > MP_PRIO sent by Host_A to Host_B contains the following fields: > > > > Path =3D (ADDR-ID-A, ADDR-ID-B), where > > ADDR-ID-A: one of Host_A's addresses; value 255 =3D all; > > ADDR-ID-B: one of Host_B's addresses; value 255 =3D all; > > B-flag: (use/don't use) path contained in this option > > S-flag: (use only one path/use any number of paths) > > > > > > Operation: > > - Host_A can refer to unavailable paths via available paths due to the > explicit use of address-ids. This also permits sending an MP_PRIO option > redundantly on multiple paths. > > > > - Host_A can refer to a specific interface, e.g. IP_A, by selecting all > paths that terminate at this interface, i.e. path =3D (IP_A, all). > > > > - Through consecutive MP_PRIO messages, Host_A can specify (and update) t= he > subset of paths it wants Host_B to consider for data transmission. > > > > - Host_B is not bound to use this subset of paths for data transmission. > However, if a certain interface of Host_A is not contained in any of the > paths of this subset, Host_B should consider this interface unavailable a= nd > not use any of the corresponding paths for data transmission. > > > > - The S-flag setting "use only one path" is binding. This path can be > selected by Host_B subject to the same constraints as mentioned in the pr= ior > bullet. When an MP_PRIO option arrives, path-re-selection should always > occur AFTER the B-flag- and path-fields of the MP_PRIO option have been > evaluated, since they may change the subset of recommended paths. > > > > - If multiple MP_PRIO options are contained in one TCP options header, th= ey > should be evaluated in the order they appear in the header. > > > > - There is no explicit confirmation of MP_PRIO. Host_A can implicitly der= ive > MP_PRIO's delivery from acks and/or packets arriving from Host B. > > > > > > Use cases/examples: > > > > 1. Set [IP_A, IP_B] as backup path: > > MP_PRIO: path =3D [IP_A, IP_B], B =3D(don't use), S =3D(use any number) > > > > 2. IP_A has become unavailable: > > MP_PRIO: path =3D [IP_A, all], B =3D(don't use), S =3D(use any number) > > > > 3. IP_A is available again: > > MP_PRIO: path=3D[IP_A, all], B =3D(use), S =3D(use any number) > > > > 4. Use only one path, doesn't matter which one: > > MP_PRIO: path=3D[all, all], B =3D(use), S =3D(use only one path) > > > > 5. Use only one path among [IP_A, IP_B] and [IP_A', IP_B']: > > Add 2 MP_PRIOs into header: > > MP_PRIO: path =3D [IP_A, IP_B], B =3D(use), S =3D(either setting) > > MP_PRIO: path =3D [IP_A', IP_B'], B =3D(use), S =3D(use only one path) > > > > > > 6. Switch one selected path from [IP_A, IP_B] to [IP_A', IP_B']: > > Add 2 MP_PRIOs into header: > > MP_PRIO: [IP_A, IP_B], B =3D (don't use), S =3D (either setting) > > MP_PRIO: [IP_A', IP_B'], B =3D (use), S =3D (use only one path) > > > > > > 7. Switch one path from interface IP_A to IP_A': > > Add 2 MP_PRIOs into header: > > MP_PRIO: [IP_A, all], B =3D (don't use), S =3D (either setting) > > MP_PRIO: [IP_A', all], B =3D (use), S =3D (use only one path) > > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > >