From miroslav.popovic@epfl.ch  Mon Jun  6 09:57:37 2011
Return-Path: <miroslav.popovic@epfl.ch>
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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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 <miroslav.popovic@epfl.ch>
To: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: Question about receiving window
Thread-Index: AcwkatOknVWOyn5zRGGJFGq4elDQvw==
Date: Mon, 6 Jun 2011 16:57:32 +0000
Message-ID: <D4FD16C4FE1EDA4BBF3C1CC556EB6C1847D8AF5D@REXM3.intranet.epfl.ch>
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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"FR-CH" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US">Dear all,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">We are doing some experiments w=
ith MPTCP and we have a question about it.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">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.&nbsp; We would appreciate any help concerni=
ng this.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Thanks,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Miroslav Popovic<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
</body>
</html>

--_000_D4FD16C4FE1EDA4BBF3C1CC556EB6C1847D8AF5DREXM3intranetep_--

From internet-drafts@ietf.org  Tue Jun  7 06:35:15 2011
Return-Path: <internet-drafts@ietf.org>
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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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: <Michael.Scharf@alcatel-lucent.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FB521F84E9 for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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" <Michael.Scharf@alcatel-lucent.com>
To: "mptcp" <multipathtcp@ietf.org>
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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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: <yoshifumi.nishida@gmail.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314AA1F0C40 for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; Wed, 15 Jun 2011 02:02:28 -0700 (PDT)
Received: by iwn39 with SMTP id 39so160051iwn.31 for <multipathtcp@ietf.org>; 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: <D4FD16C4FE1EDA4BBF3C1CC556EB6C1847D8AF5D@REXM3.intranet.epfl.ch>
References: <D4FD16C4FE1EDA4BBF3C1CC556EB6C1847D8AF5D@REXM3.intranet.epfl.ch>
Date: Wed, 15 Jun 2011 02:02:27 -0700
X-Google-Sender-Auth: IDJ2wm_tkhOu525SC0UgCGN8nek
Message-ID: <BANLkTim-m5tHvWuntmdcPmXYzBYjBvLG8A@mail.gmail.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
To: Popovic Miroslav <miroslav.popovic@epfl.ch>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "multipathtcp@ietf.org" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2011 09:02:29 -0000

Hi Popovic,

2011/6/6 Popovic Miroslav <miroslav.popovic@epfl.ch>:
> 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: <internet-drafts@ietf.org>
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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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: <andrewmcgr@gmail.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F86F11E80C7 for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; Wed, 15 Jun 2011 15:57:38 -0700 (PDT)
Received: by pzk5 with SMTP id 5so773681pzk.31 for <multipathtcp@ietf.org>; 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 <andrewmcgr@gmail.com>
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 <nishida@sfc.wide.ad.jp>, Philip Eardley <philip.eardley@bt.com>, Alan Ford <alan.ford@roke.co.uk>, Costin Raiciu <c.raiciu@cs.ucl.ac.uk>, Mark Handley <M.Handley@cs.ucl.ac.uk>, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>, 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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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: <prvs=21485fedb3=alan.ford@roke.co.uk>
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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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" <alan.ford@roke.co.uk>
To: "Andrew McGregor" <andrewmcgr@gmail.com>, "Yoshifumi Nishida" <nishida@sfc.wide.ad.jp>, "Philip Eardley" <philip.eardley@bt.com>, "Costin Raiciu" <c.raiciu@cs.ucl.ac.uk>, "Mark Handley" <M.Handley@cs.ucl.ac.uk>, "Olivier Bonaventure" <Olivier.Bonaventure@uclouvain.be>, <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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: <andrewmcgr@gmail.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792D111E81E9 for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; Thu, 16 Jun 2011 02:13:02 -0700 (PDT)
Received: by pwi5 with SMTP id 5so575732pwi.31 for <multipathtcp@ietf.org>; 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 <andrewmcgr@gmail.com>
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: <D843316A-CD95-414C-8D4F-EFC285857705@gmail.com>
References: <0A2BA2A4-A3AE-450B-8061-9B624CD4741B@gmail.com> <2181C5F19DD0254692452BFF3EAF1D680D0E23DB@rsys005a.comm.ad.roke.co.uk>
To: "Ford, Alan" <alan.ford@roke.co.uk>
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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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: <internet-drafts@ietf.org>
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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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: <georg.hampel@alcatel-lucent.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9ED29E801D for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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 <multipathtcp@ietf.org>; 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 <multipathtcp@ietf.org>; 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)" <georg.hampel@alcatel-lucent.com>
To: "multipathtcp@ietf.org" <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\)" <thierry.klein@alcatel-lucent.com>
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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"FuturaA Bk BT";
	panose-1:2 11 5 2 2 2 4 2 3 3;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"FuturaA Bk BT";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:#606420;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3D"#606420">

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>All,<o:p></o:p></span></font></p>

<pre><font size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-famil=
y:Arial'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>We=
 have uploaded a new I-D.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'><o=
:p>&nbsp;</o:p></span></font></pre><pre><font
size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>Ti=
tle: Enhancements to Improve the Applicability of Multipath TCP to Wireless=
 Access Networks<o:p></o:p></span></font></pre>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'>Authors: Georg Hampel, Thierry=
 Klein<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<pre><font size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-famil=
y:Arial'>Filename: draft-hampel-mptcp-applicability-wireless-networks-00.tx=
t<o:p></o:p></span></font></pre>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>URL: <a
href=3D"http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-wi=
reless-networks/">http://datatracker.ietf.org/doc/draft-hampel-mptcp-applic=
ability-wireless-networks/</a><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<pre><span class=3Dmh><font size=3D2 face=3DArial><span style=3D'font-size:=
10.0pt;
font-family:Arial'>Abstract:</span></font></span><font face=3DArial><span
style=3D'font-family:Arial'><o:p></o:p></span></font></pre>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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.&nbsp; 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.&nbsp; 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.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>IMPORTANT COMMENTS: Apart from a variety of recommendati=
ons for
research, the I-D proposes the following signaling and policy enhancements:=
 <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>MP_SELECT option:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>The host sends this option to enforce path-selective
operation on its peer.&nbsp; 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).<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>AVAIL_ADDR/UNAVAIL_ADDR option(s):<o:p></o:p></span></fo=
nt></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>The host sends this option to inform its peer about the
availability/unavailability status of an interface referred to via an addre=
ss
id.&nbsp; 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&#8217;s interface availability chang=
es.
There are multiple use cases for this option (Section 3.6, Section 4.4 and
Section 4.5).<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>DEFER_ADDR option: <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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).<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>ADD_ADDR option:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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).<o:p></o:=
p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>JOIN_ADDR option: <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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.<o:p></o:p>=
</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>DSS insertion policy for bulk transfer: <o:p></o:p></spa=
n></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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).<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'>Please take the details from t=
he
corresponding sections of the document. Comments are welcome. Thank you.<o:=
p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'>Regards,<o:p></o:p></span></fo=
nt></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'>Georg Hampel<o:p></o:p></span>=
</font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

--_000_154773479ED2314980CB638A48FC443484D61294USNAVSXCHMBSA2n_--

From prvs=0153e612c9=alan.ford@roke.co.uk  Tue Jun 21 02:49:56 2011
Return-Path: <prvs=0153e612c9=alan.ford@roke.co.uk>
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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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" <alan.ford@roke.co.uk>
To: "Hampel, K Georg \(K Georg\)" <georg.hampel@alcatel-lucent.com>, <multipathtcp@ietf.org>
Cc: "Klein, Thierry E \(Thierry\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:"FuturaA Bk BT";}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"FuturaA Bk BT";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#606420;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:windowtext;}
span.mh
	{mso-style-name:mh;}
span.EmailStyle23
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-GB link=3Dblue vlink=3D"#606420">

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>Hello
Georg, Thierry,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>Thanks
for writing this &#8211; it covers an important and interesting topic. =
I&#8217;ve
had a chance to read it, now, and have some =
comments.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>3.3:
It is definitely intentional that you can use MPTCP with no changes to =
send
data resiliently on many paths. I&#8217;ll expand the text in the =
protocol
draft slightly to discuss processing the same mappings on different =
subflows.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>3.4:
Agreed, this (fluctuations in path throughput/delay) is a very valid =
concern
and one that we discuss considerably in the API draft. &nbsp;It is an =
issue
where users are best placed to drive the development of =
solutions.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>3.7:
This idea is sensible, but I would be reluctant to mandate it. &nbsp;I =
think
some text like this may be sufficient: &#8220;An implementation SHOULD =
send DSS
options that cover multiple segments multiple times, to reduce the need =
for
unnecessary buffering at the receiver.&nbsp; It is RECOMMENDED that a =
sender
repeats the DSS option until a DATA ACK for some data covered by this =
mapping
is received.&#8221;<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>&#8220;Path
Availability&#8221; &#8211; 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?<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>Throughout
the rest of this document, I struggle to see what difference there is =
between path
(or interface) availability, and address availability.&nbsp; We have the
ADD_ADDR and REMOVE_ADDR options to indicate the availability or loss of
availability of an address (interface) on a host.&nbsp; What is =
(UN)AVAIL_ADDR
giving over and above this? Why separate the creation of the mapping and =
the
signalling of the availability?<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>Some
points on 4.4:<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>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) &#8211; I can&#8217;t see that we can change =
that. &nbsp;If
an end host was desperate to stop receiving traffic on an interface, it =
could
drop the subflow.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>If
I understand your comment correctly, you&#8217;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?&nbsp; I guess we could adapt MP_PRIO to achieve this, by =
having
another value that means &#8220;use me and me alone&#8221;.&nbsp; =
Although I
think I need more convincing that it adds value!<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>In
4.4.2, you talk about BBM in the scenario of a radio <i>knowing</i> that =
it is
going to take down its interface to attach to a new network.&nbsp; You =
can do
this already cleanly &#8211; just FIN the old path (without a DATA FIN) =
and
bring up the new one. &nbsp;What is your proposal =
adding?<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>5.1
is an interesting problem and one that Mark led some discussion of at =
the last
IETF.&nbsp; As with the discussion about AVAIL_ADDR, I don&#8217;t see =
the
point of JOIN_ADDR and ADD_ADDR separations, but DEFER_ADDR (or =
&#8220;USE_THIS_ADDR!&#8221;)
is an interesting idea that I need to think about some =
more!<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>Regards,<o:p><=
/o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>Alan<o:p></o:p=
></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0cm 0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> multipathtcp-bounces@ietf.org
[mailto:multipathtcp-bounces@ietf.org] <b>On Behalf Of </b>Hampel, K =
Georg (K
Georg)<br>
<b>Sent:</b> 16 June 2011 16:03<br>
<b>To:</b> multipathtcp@ietf.org<br>
<b>Cc:</b> Klein, Thierry E (Thierry)<br>
<b>Subject:</b> [multipathtcp] New I-D: Enhancements to Improve the
Applicability of Multipath TCP to Wireless Access =
Networks<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>All,<o:p></o:=
p></span></p>

<pre><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></pre>=
<pre><span
lang=3DEN-US style=3D'font-family:"Arial","sans-serif"'>We have uploaded =
a new I-D.<o:p></o:p></span></pre><pre><span
lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></pre>=
<pre><span
lang=3DEN-US style=3D'font-family:"Arial","sans-serif"'>Title: =
Enhancements to Improve the Applicability of Multipath TCP to Wireless =
Access Networks<o:p></o:p></span></pre>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Authors: =
Georg
Hampel, Thierry Klein<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<pre><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>Filename: =
draft-hampel-mptcp-applicability-wireless-networks-00.txt<o:p></o:p></spa=
n></pre>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>URL:
<a
href=3D"http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-=
wireless-networks/">http://datatracker.ietf.org/doc/draft-hampel-mptcp-ap=
plicability-wireless-networks/</a><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<pre><span class=3Dmh><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>Abstract:</span></span><span
lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p></o:p></span></pre>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>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.&nbsp; The
analysis attempts to identify use cases, benefits as well as technical =
and
functional obstacles encountered in the current version of the =
protocol.&nbsp;
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.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>IMPORTANT
COMMENTS: Apart from a variety of recommendations for research, the I-D
proposes the following signaling and policy enhancements: =
<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>MP_SELECT
option:<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>The
host sends this option to enforce path-selective operation on its =
peer.&nbsp;
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).<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>AVAIL_ADDR/UNAVAIL_ADDR
option(s):<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>The
host sends this option to inform its peer about the =
availability/unavailability
status of an interface referred to via an address id.&nbsp; 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&#8217;s interface availability changes. There =
are
multiple use cases for this option (Section 3.6, Section 4.4 and Section =
4.5).<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>DEFER_ADDR
option: <o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>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).<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>ADD_ADDR
option:<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>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).<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>JOIN_ADDR
option: <o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>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.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>DSS
insertion policy for bulk transfer: <o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>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).<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Please take =
the
details from the corresponding sections of the document. Comments are =
welcome.
Thank you.<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Regards,<o:p>=
</o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Georg =
Hampel<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01CC2FF8.87E2CCF8--

From christoph.paasch@uclouvain.be  Tue Jun 21 04:14:12 2011
Return-Path: <christoph.paasch@uclouvain.be>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B279F11E8079 for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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 <christoph.paasch@uclouvain.be>
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\)" <thierry.klein@alcatel-lucent.com>
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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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: <iesg-secretary@ietf.org>
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 <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
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: <draft-ietf-mptcp-congestion-05.txt> (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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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'
  <draft-ietf-mptcp-congestion-05.txt> 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: <georg.hampel@alcatel-lucent.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B5411E827F for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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 <multipathtcp@ietf.org>; 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)" <georg.hampel@alcatel-lucent.com>
To: "Ford, Alan" <alan.ford@roke.co.uk>, "multipathtcp@ietf.org" <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\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40"
xmlns:ns1=3D"http://schemas.microsoft.com/office/2004/12/omml">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--a:link
	{mso-style-priority:99;}
span.MSOHYPERLINK
	{mso-style-priority:99;}
a:visited
	{mso-style-priority:99;}
span.MSOHYPERLINKFOLLOWED
	{mso-style-priority:99;}
p.MSOPLAINTEXT
	{mso-style-priority:99;}
li.MSOPLAINTEXT
	{mso-style-priority:99;}
div.MSOPLAINTEXT
	{mso-style-priority:99;}
pre
	{mso-style-priority:99;}
span.HTMLPREFORMATTEDCHAR
	{mso-style-priority:99;}
span.PLAINTEXTCHAR
	{mso-style-priority:99;}

 /* Font Definitions */
 @font-face
	{font-family:"FuturaA Bk BT";
	panose-1:2 11 5 2 2 2 4 2 3 3;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"FuturaA Bk BT";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:#606420;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.HTMLPreformattedChar
	{font-family:Consolas;}
span.PlainTextChar
	{font-family:Consolas;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle24
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3D"#606420">

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hello Alan,<o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks for reading the draft. &nbsp;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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Georg<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt;font-family:"Times=
 New Roman"'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Ford, Al=
an
[mailto:alan.ford@roke.co.uk] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, June 21, 2011=
 5:50
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Hampel, K Georg (K Georg=
);
multipathtcp@ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Klein, Thierry E (Thierr=
y)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [multipathtcp] =
New
I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless
Access Networks</span></font><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-family:"Times New Roman"'><o:p></o:p></span>=
</font></p>

</div>

<p class=3DMsoNormal><font size=3D2 face=3D"FuturaA Bk BT"><span style=3D'f=
ont-size:
11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Hello Georg,
Thierry,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Thanks for wri=
ting
this &#8211; it covers an important and interesting topic. I&#8217;ve had a
chance to read it, now, and have some comments.<o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>3.3: It is
definitely intentional that you can use MPTCP with no changes to send data
resiliently on many paths. I&#8217;ll expand the text in the protocol draft
slightly to discuss processing the same mappings on different subflows.<o:p=
></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>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. &nbsp;It is an issue where users are
best placed to drive the development of solutions.<o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>3.7: This idea=
 is
sensible, but I would be reluctant to mandate it. &nbsp;I think some text l=
ike
this may be sufficient: &#8220;An implementation SHOULD send DSS options th=
at
cover multiple segments multiple times, to reduce the need for unnecessary
buffering at the receiver.&nbsp; 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.&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>&#8220;Path Av=
ailability&#8221;
&#8211; 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?<o:p></o:p></span></fon=
t></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Throughout the=
 rest
of this document, I struggle to see what difference there is between path (=
or
interface) availability, and address availability.&nbsp; 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.&nbsp; What is (UN)AVAIL_ADDR giving over =
and
above this? Why separate the creation of the mapping and the signalling of =
the
availability?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>[G.H.] The &#8220;P=
ath
availability&#8221; option shows up in sections 3.6 and 4.4.2. Here is an
example that applies to section 3.6:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>A multi-homed mobil=
e
downloads a data stream from a server using 2 interfaces, say, &nbsp;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). <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>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 &#8220;4G&#8221; interface is currently NOT good and it can immediately
redirect all data including 4G-retransmissions to the &#8220;WiFi&#8221; pa=
th.
The mobile should NOT tear down the &#8220;4G&#8221; 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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Some points on=
 4.4:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>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) &#8211; I can&#8217;t see that we can change that. &nbsp;If an end h=
ost
was desperate to stop receiving traffic on an interface, it could drop the
subflow.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>If I understan=
d your
comment correctly, you&#8217;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?&nbsp; I guess we could adapt MP_PRIO to achieve this, by having
another value that means &#8220;use me and me alone&#8221;.&nbsp; Although =
I
think I need more convincing that it adds value!<o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>[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&#8217;s sender since this simplifies the host&#8217;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 &#8220;switchin=
g
messages&#8221; get lost.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>In 4.4.2, you =
talk
about BBM in the scenario of a radio <i><span style=3D'font-style:italic'>k=
nowing</span></i>
that it is going to take down its interface to attach to a new network.&nbs=
p;
You can do this already cleanly &#8211; just FIN the old path (without a DA=
TA
FIN) and bring up the new one. &nbsp;What is your proposal adding?<o:p></o:=
p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DCalibri><span lang=
=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>[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.<o:p></o:p></sp=
an></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>5.1 is an
interesting problem and one that Mark led some discussion of at the last
IETF.&nbsp; As with the discussion about AVAIL_ADDR, I don&#8217;t see the
point of JOIN_ADDR and ADD_ADDR separations, but DEFER_ADDR (or
&#8220;USE_THIS_ADDR!&#8221;) is an interesting idea that I need to think a=
bout
some mor</span></font><font color=3Dnavy face=3DCalibri><span lang=3DEN-GB
style=3D'font-family:Calibri;color:navy'>e</span></font><font color=3D"#1f4=
97d"
face=3DCalibri><span lang=3DEN-GB style=3D'font-family:Calibri;color:#1F497=
D'>!<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>[G.H.] I think Mark=
 had a
more generic proxy solution in mind. The &#8220;transparent&#8221; 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 (&#8220;USE_THIS_ADDR&#8221; may indeed =
be
clearer).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Regards,<o:p><=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Alan<o:p></o:p=
></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] <b><sp=
an
style=3D'font-weight:bold'>On Behalf Of </span></b>Hampel, K Georg (K Georg=
)<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> 16 June 2011 16:03<br>
<b><span style=3D'font-weight:bold'>To:</span></b> multipathtcp@ietf.org<br=
>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Klein, Thierry E (Thierr=
y)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [multipathtcp] New =
I-D:
Enhancements to Improve the Applicability of Multipath TCP to Wireless Acce=
ss
Networks<o:p></o:p></span></font></p>

</div>

</div>

<p class=3DMsoNormal><font size=3D2 face=3D"FuturaA Bk BT"><span lang=3DEN-=
GB
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>All,<o:p></o:p></span></font></p>

<pre><font size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-famil=
y:Arial'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>We=
 have uploaded a new I-D.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'><o=
:p>&nbsp;</o:p></span></font></pre><pre><font
size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>Ti=
tle: Enhancements to Improve the Applicability of Multipath TCP to Wireless=
 Access Networks<o:p></o:p></span></font></pre>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'>Authors: Georg Hampel, Thierry=
 Klein<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<pre><font size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-famil=
y:Arial'>Filename: draft-hampel-mptcp-applicability-wireless-networks-00.tx=
t<o:p></o:p></span></font></pre>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>URL: <a
href=3D"http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-wi=
reless-networks/">http://datatracker.ietf.org/doc/draft-hampel-mptcp-applic=
ability-wireless-networks/</a><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<pre><span class=3Dmh><font size=3D2 face=3DArial><span style=3D'font-size:=
10.0pt;
font-family:Arial'>Abstract:</span></font></span><font face=3DArial><span
style=3D'font-family:Arial'><o:p></o:p></span></font></pre>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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.&nbsp; 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.&nbsp; 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.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>IMPORTANT COMMENTS: Apart from a variety of recommendati=
ons
for research, the I-D proposes the following signaling and policy enhanceme=
nts:
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>MP_SELECT option:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>The host sends this option to enforce path-selective
operation on its peer.&nbsp; 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).<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>AVAIL_ADDR/UNAVAIL_ADDR option(s):<o:p></o:p></span></fo=
nt></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>The host sends this option to inform its peer about the
availability/unavailability status of an interface referred to via an addre=
ss
id.&nbsp; 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&#8217;s interface availabili=
ty
changes. There are multiple use cases for this option (Section 3.6, Section=
 4.4
and Section 4.5).<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>DEFER_ADDR option: <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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).<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>ADD_ADDR option:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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).=
<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>JOIN_ADDR option: <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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.<o:p></o:p>=
</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>DSS insertion policy for bulk transfer: <o:p></o:p></spa=
n></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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).<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'>Please take the details from t=
he
corresponding sections of the document. Comments are welcome. Thank you.<o:=
p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'>Regards,<o:p></o:p></span></fo=
nt></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'>Georg Hampel<o:p></o:p></span>=
</font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</div>

</body>

</html>

--_000_154773479ED2314980CB638A48FC443484DC89D5USNAVSXCHMBSA2n_--

From georg.hampel@alcatel-lucent.com  Tue Jun 21 08:57:38 2011
Return-Path: <georg.hampel@alcatel-lucent.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8D411E8276 for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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)" <georg.hampel@alcatel-lucent.com>
To: "christoph.paasch@uclouvain.be" <christoph.paasch@uclouvain.be>, "multipathtcp@ietf.org" <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\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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: <prvs=1153d46856=alan.ford@roke.co.uk>
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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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" <alan.ford@roke.co.uk>
To: "Hampel, K Georg \(K Georg\)" <georg.hampel@alcatel-lucent.com>, <multipathtcp@ietf.org>
Cc: "Klein, Thierry E \(Thierry\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" =
xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" =
xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" =
xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" =
xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" =
xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig=
nature" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" =
xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/=
" =
xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub=
lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" =
xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:"FuturaA Bk BT";}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"FuturaA Bk BT";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#606420;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.htmlpreformattedchar0
	{mso-style-name:htmlpreformattedchar;
	mso-style-priority:99;
	font-family:Consolas;}
span.plaintextchar0
	{mso-style-name:plaintextchar;
	mso-style-priority:99;
	font-family:Consolas;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:windowtext;}
span.EmailStyle24
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle25
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:navy;}
span.mh
	{mso-style-name:mh;}
span.EmailStyle27
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-GB link=3Dblue vlink=3D"#606420">

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>Hi
Georg, all,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>To
extract two key points from your mail below:<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>[G.H.] The &#8220;Path availability&#8221; option shows up =
in
sections 3.6 and 4.4.2. Here is an example that applies to section =
3.6:<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>A multi-homed mobile downloads a data stream from a server =
using 2
interfaces, say, &nbsp;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). =
<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>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 =
&#8220;4G&#8221;
interface is currently NOT good and it can immediately redirect all data
including 4G-retransmissions to the &#8220;WiFi&#8221; path. The mobile =
should
NOT tear down the &#8220;4G&#8221; 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.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>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.&nbsp; At the moment , we do not have any =
significant
retransmission recommendations since we have relatively little =
real-world
experience to base it on.&nbsp; But an aggressive retransmission =
strategy would
cope with this scenario quite well.&nbsp; 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).<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>[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.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>In
this case, you are relying on the wireless network infrastructure =
retaining
state (i.e. &nbsp;NATs) for the connection while the host uses another =
network.&nbsp;
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 &#8220;use
me and me alone&#8221; subflow).<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>If
we were to modify the MP_PRIO option to take an Address ID (which is =
something
we&#8217;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).&nbsp; Shortcuts of a second bit to say =
&#8220;Do
not use&#8221; or &#8220;use exclusively&#8221; could also help =
here.&nbsp;
Might this cover all cases?<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>Regards,<o:p><=
/o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>Alan<o:p></o:p=
></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0cm 0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Hampel, K Georg (K Georg)
[mailto:georg.hampel@alcatel-lucent.com] <br>
<b>Sent:</b> 21 June 2011 16:44<br>
<b>To:</b> Ford, Alan; multipathtcp@ietf.org<br>
<b>Cc:</b> Klein, Thierry E (Thierry)<br>
<b>Subject:</b> RE: [multipathtcp] New I-D: Enhancements to Improve the
Applicability of Multipath TCP to Wireless Access =
Networks<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>Hello Alan,<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>Thanks for reading the draft. &nbsp;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.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>Regards,<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>Georg<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span =
lang=3DEN-US
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'>

<hr size=3D2 width=3D"100%" align=3Dcenter>

</span></div>

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Ford, Alan =
[mailto:alan.ford@roke.co.uk] <br>
<b>Sent:</b> Tuesday, June 21, 2011 5:50 AM<br>
<b>To:</b> Hampel, K Georg (K Georg); multipathtcp@ietf.org<br>
<b>Cc:</b> Klein, Thierry E (Thierry)<br>
<b>Subject:</b> RE: [multipathtcp] New I-D: Enhancements to Improve the
Applicability of Multipath TCP to Wireless Access Networks</span><span
lang=3DEN-US style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>Hello
Georg, Thierry,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>Thanks
for writing this &#8211; it covers an important and interesting topic.
I&#8217;ve had a chance to read it, now, and have some =
comments.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>3.3:
It is definitely intentional that you can use MPTCP with no changes to =
send
data resiliently on many paths. I&#8217;ll expand the text in the =
protocol
draft slightly to discuss processing the same mappings on different =
subflows.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>3.4:
Agreed, this (fluctuations in path throughput/delay) is a very valid =
concern
and one that we discuss considerably in the API draft. &nbsp;It is an =
issue
where users are best placed to drive the development of =
solutions.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>3.7:
This idea is sensible, but I would be reluctant to mandate it. &nbsp;I =
think
some text like this may be sufficient: &#8220;An implementation SHOULD =
send DSS
options that cover multiple segments multiple times, to reduce the need =
for
unnecessary buffering at the receiver.&nbsp; It is RECOMMENDED that a =
sender
repeats the DSS option until a DATA ACK for some data covered by this =
mapping
is received.&#8221;<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>&#8220;Path
Availability&#8221; &#8211; 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?<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>Throughout
the rest of this document, I struggle to see what difference there is =
between
path (or interface) availability, and address availability.&nbsp; We =
have the
ADD_ADDR and REMOVE_ADDR options to indicate the availability or loss of
availability of an address (interface) on a host.&nbsp; What is =
(UN)AVAIL_ADDR
giving over and above this? Why separate the creation of the mapping and =
the
signalling of the availability?<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>[G.H.] The &#8220;Path availability&#8221; option shows up =
in
sections 3.6 and 4.4.2. Here is an example that applies to section =
3.6:<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>A multi-homed mobile downloads a data stream from a server =
using 2
interfaces, say, &nbsp;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). =
<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>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 =
&#8220;4G&#8221;
interface is currently NOT good and it can immediately redirect all data
including 4G-retransmissions to the &#8220;WiFi&#8221; path. The mobile =
should
NOT tear down the &#8220;4G&#8221; 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.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>Some
points on 4.4:<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>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) &#8211; I can&#8217;t see that we can change =
that.
&nbsp;If an end host was desperate to stop receiving traffic on an =
interface,
it could drop the subflow.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>If
I understand your comment correctly, you&#8217;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?&nbsp; I guess we could adapt MP_PRIO to achieve this, by =
having
another value that means &#8220;use me and me alone&#8221;.&nbsp; =
Although I
think I need more convincing that it adds value!<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>[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&#8217;s sender since =
this
simplifies the host&#8217;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 &#8220;switching messages&#8221; get lost.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>In
4.4.2, you talk about BBM in the scenario of a radio <i>knowing</i> that =
it is
going to take down its interface to attach to a new network.&nbsp; You =
can do
this already cleanly &#8211; just FIN the old path (without a DATA FIN) =
and
bring up the new one. &nbsp;What is your proposal =
adding?<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:navy'><o:p>&nbsp;</o:p>=
</span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>[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.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>5.1
is an interesting problem and one that Mark led some discussion of at =
the last
IETF.&nbsp; As with the discussion about AVAIL_ADDR, I don&#8217;t see =
the
point of JOIN_ADDR and ADD_ADDR separations, but DEFER_ADDR (or
&#8220;USE_THIS_ADDR!&#8221;) is an interesting idea that I need to =
think about
some mor</span><span =
style=3D'font-family:"Calibri","sans-serif";color:navy'>e</span><span
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>!<o:p></o:p></=
span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>[G.H.] I think Mark had a more generic proxy solution in =
mind. The
&#8220;transparent&#8221; 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
(&#8220;USE_THIS_ADDR&#8221; may indeed be =
clearer).<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>Regards,<o:p><=
/o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>Alan<o:p></o:p=
></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o=
:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0cm 0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> multipathtcp-bounces@ietf.org
[mailto:multipathtcp-bounces@ietf.org] <b>On Behalf Of </b>Hampel, K =
Georg (K
Georg)<br>
<b>Sent:</b> 16 June 2011 16:03<br>
<b>To:</b> multipathtcp@ietf.org<br>
<b>Cc:</b> Klein, Thierry E (Thierry)<br>
<b>Subject:</b> [multipathtcp] New I-D: Enhancements to Improve the
Applicability of Multipath TCP to Wireless Access =
Networks<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>All,<o:p></o:=
p></span></p>

<pre><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></pre>=
<pre><span
lang=3DEN-US style=3D'font-family:"Arial","sans-serif"'>We have uploaded =
a new I-D.<o:p></o:p></span></pre><pre><span
lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></pre>=
<pre><span
lang=3DEN-US style=3D'font-family:"Arial","sans-serif"'>Title: =
Enhancements to Improve the Applicability of Multipath TCP to Wireless =
Access Networks<o:p></o:p></span></pre>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Authors: =
Georg
Hampel, Thierry Klein<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<pre><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>Filename: =
draft-hampel-mptcp-applicability-wireless-networks-00.txt<o:p></o:p></spa=
n></pre>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>URL:
<a
href=3D"http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-=
wireless-networks/">http://datatracker.ietf.org/doc/draft-hampel-mptcp-ap=
plicability-wireless-networks/</a><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<pre><span class=3Dmh><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>Abstract:</span></span><span
lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p></o:p></span></pre>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>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.&nbsp; The
analysis attempts to identify use cases, benefits as well as technical =
and
functional obstacles encountered in the current version of the =
protocol.&nbsp;
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.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>IMPORTANT
COMMENTS: Apart from a variety of recommendations for research, the I-D
proposes the following signaling and policy enhancements: =
<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>MP_SELECT
option:<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>The
host sends this option to enforce path-selective operation on its =
peer.&nbsp;
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).<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>AVAIL_ADDR/UNAVAIL_ADDR
option(s):<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>The
host sends this option to inform its peer about the =
availability/unavailability
status of an interface referred to via an address id.&nbsp; 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&#8217;s interface availability changes. There =
are
multiple use cases for this option (Section 3.6, Section 4.4 and Section =
4.5).<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>DEFER_ADDR
option: <o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>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).<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>ADD_ADDR
option:<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>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).<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>JOIN_ADDR
option: <o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>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.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>DSS
insertion policy for bulk transfer: <o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'>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).<o:p></o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Please take =
the
details from the corresponding sections of the document. Comments are =
welcome.
Thank you.<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Regards,<o:p>=
</o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Georg =
Hampel<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoPlainText><span lang=3DEN-US =
style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

</div>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01CC3031.12E5F250--

From touch@isi.edu  Tue Jun 21 09:39:39 2011
Return-Path: <touch@isi.edu>
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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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 <touch@isi.edu>
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" <alan.ford@roke.co.uk>
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\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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: <georg.hampel@alcatel-lucent.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94109228011 for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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)" <georg.hampel@alcatel-lucent.com>
To: "Ford, Alan" <alan.ford@roke.co.uk>, "multipathtcp@ietf.org" <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\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:st=3D"&#1;" =
xmlns=3D"http://www.w3.org/TR/REC-html40"
xmlns:ns2=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/"
xmlns:ns3=3D"http://schemas.microsoft.com/office/2006/digsig-setup"
xmlns:ns4=3D"http://schemas.microsoft.com/office/2006/digsig"
xmlns:ns5=3D"http://schemas.openxmlformats.org/package/2006/digital-signatu=
re"
xmlns:ns6=3D"http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:ns1=3D"http://schemas.microsoft.com/office/2004/12/omml"
xmlns:ns7=3D"http://schemas.openxmlformats.org/package/2006/relationships"
xmlns:ns8=3D"http://microsoft.com/sharepoint/webpartpages"
xmlns:ns9=3D"http://schemas.microsoft.com/exchange/services/2006/types"
xmlns:ns10=3D"http://schemas.microsoft.com/exchange/services/2006/messages"
xmlns:ns11=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/"
xmlns:ns12=3D"http://microsoft.com/webservices/SharePointPortalServer/Publi=
shedLinksService"
xmlns:ns13=3D"urn:schemas-microsoft-com:">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--a:link
	{mso-style-priority:99;}
span.MSOHYPERLINK
	{mso-style-priority:99;}
a:visited
	{mso-style-priority:99;}
span.MSOHYPERLINKFOLLOWED
	{mso-style-priority:99;}
p.MSOPLAINTEXT
	{mso-style-priority:99;}
li.MSOPLAINTEXT
	{mso-style-priority:99;}
div.MSOPLAINTEXT
	{mso-style-priority:99;}
pre
	{mso-style-priority:99;}
span.HTMLPREFORMATTEDCHAR
	{mso-style-priority:99;}
span.PLAINTEXTCHAR
	{mso-style-priority:99;}
span.HTMLPREFORMATTEDCHAR0
	{mso-style-priority:99;}
span.PLAINTEXTCHAR0
	{mso-style-priority:99;}

 /* Font Definitions */
 @font-face
	{font-family:"FuturaA Bk BT";
	panose-1:2 11 5 2 2 2 4 2 3 3;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"FuturaA Bk BT";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:#606420;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.HTMLPreformattedChar
	{font-family:Consolas;}
span.PlainTextChar
	{font-family:Consolas;}
span.htmlpreformattedchar0
	{font-family:Consolas;}
span.plaintextchar0
	{font-family:Consolas;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle24
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle25
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle27
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle28
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3D"#606420">

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Alan, all,<o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>On address availability: <o:p></o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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 &#8220;link quality&#8221;. (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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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&#8217;s new interface.<o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>In summary: The address-id-equipped
MP_PRIO option should do the job.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>On BBM:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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?=
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Georg<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt;font-family:"Times=
 New Roman"'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Ford, Al=
an
[mailto:alan.ford@roke.co.uk] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, June 21, 2011=
 12:34
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Hampel, K Georg (K Georg=
);
multipathtcp@ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Klein, Thierry E (Thierr=
y)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [multipathtcp] =
New
I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless
Access Networks</span></font><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-family:"Times New Roman"'><o:p></o:p></span>=
</font></p>

</div>

<p class=3DMsoNormal><font size=3D2 face=3D"FuturaA Bk BT"><span style=3D'f=
ont-size:
11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Hi Georg, all,=
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>To extract two=
 key
points from your mail below:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>[G.H.] The &#8220;P=
ath
availability&#8221; option shows up in sections 3.6 and 4.4.2. Here is an e=
xample
that applies to section 3.6:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>A multi-homed mobil=
e
downloads a data stream from a server using 2 interfaces, say, &nbsp;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). <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>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 &#8220;4G&#8221; interface is currently NOT good an=
d it can
immediately redirect all data including 4G-retransmissions to the &#8220;Wi=
Fi&#8221; path.
The mobile should NOT tear down the &#8220;4G&#8221; 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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>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.&nbsp; 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.&nbsp; But an aggressive retransmission strategy would cope with this
scenario quite well.&nbsp; 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).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>[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.<o=
:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>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.&nbsp; 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 &#8220;use=
 me and me
alone&#8221; subflow).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>If we were to =
modify
the MP_PRIO option to take an Address ID (which is something we&#8217;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).&nbsp; Shortcuts of a second bit to say &#8220;Do not use&#8221; o=
r &#8220;use
exclusively&#8221; could also help here.&nbsp; Might this cover all cases?<=
o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Regards,<o:p><=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Alan<o:p></o:p=
></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Hampel, =
K Georg
(K Georg) [mailto:georg.hampel@alcatel-lucent.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> 21 June 2011 16:44<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Ford, Alan;
multipathtcp@ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Klein, Thierry E (Thierr=
y)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [multipathtcp] =
New
I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless
Access Networks<o:p></o:p></span></font></p>

</div>

</div>

<p class=3DMsoNormal><font size=3D2 face=3D"FuturaA Bk BT"><span lang=3DEN-=
GB
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hello Alan,<o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks for reading the draft. &nbsp;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.<o:p></o:p></span></fon=
t></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Georg<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt;font-family:"Times=
 New Roman"'>

<hr size=3D2 width=3D"100%" align=3Dcenter>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Ford, Al=
an
[mailto:alan.ford@roke.co.uk] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, June 21, 2011=
 5:50
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Hampel, K Georg (K Georg=
);
multipathtcp@ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Klein, Thierry E (Thierr=
y)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [multipathtcp] =
New
I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless
Access Networks</span></font><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-family:"Times New Roman"'><o:p></o:p></span>=
</font></p>

</div>

<p class=3DMsoNormal><font size=3D2 face=3D"FuturaA Bk BT"><span style=3D'f=
ont-size:
11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Hello Georg,
Thierry,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Thanks for wri=
ting
this &#8211; it covers an important and interesting topic. I&#8217;ve had a=
 chance to read
it, now, and have some comments.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>3.3: It is
definitely intentional that you can use MPTCP with no changes to send data
resiliently on many paths. I&#8217;ll expand the text in the protocol draft=
 slightly
to discuss processing the same mappings on different subflows.<o:p></o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>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. &nbsp;It is an issue where users are
best placed to drive the development of solutions.<o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>3.7: This idea=
 is
sensible, but I would be reluctant to mandate it. &nbsp;I think some text l=
ike
this may be sufficient: &#8220;An implementation SHOULD send DSS options th=
at cover
multiple segments multiple times, to reduce the need for unnecessary buffer=
ing
at the receiver.&nbsp; It is RECOMMENDED that a sender repeats the DSS opti=
on
until a DATA ACK for some data covered by this mapping is received.&#8221;<=
o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>&#8220;Path Av=
ailability&#8221;
&#8211; 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?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Throughout the=
 rest
of this document, I struggle to see what difference there is between path (=
or
interface) availability, and address availability.&nbsp; 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.&nbsp; What is (UN)AVAIL_ADDR giving over =
and
above this? Why separate the creation of the mapping and the signalling of =
the
availability?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>[G.H.] The &#8220;P=
ath
availability&#8221; option shows up in sections 3.6 and 4.4.2. Here is an e=
xample
that applies to section 3.6:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>A multi-homed mobil=
e
downloads a data stream from a server using 2 interfaces, say, &nbsp;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). <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>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 &#8220;4G&#8221; interface is currently NOT good an=
d it can
immediately redirect all data including 4G-retransmissions to the &#8220;Wi=
Fi&#8221; path.
The mobile should NOT tear down the &#8220;4G&#8221; 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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Some points on=
 4.4:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>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) &#8211; I can&#8217;t see that we can change that. &nbsp;If an end h=
ost was
desperate to stop receiving traffic on an interface, it could drop the subf=
low.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>If I understan=
d your
comment correctly, you&#8217;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?&nbsp; =
I
guess we could adapt MP_PRIO to achieve this, by having another value that
means &#8220;use me and me alone&#8221;.&nbsp; Although I think I need more=
 convincing that
it adds value!<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>[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&#8217;s sender since this simplifies the host&#8217;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 &#8220;switching messa=
ges&#8221; get
lost.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>In 4.4.2, you =
talk
about BBM in the scenario of a radio <i><span style=3D'font-style:italic'>k=
nowing</span></i>
that it is going to take down its interface to attach to a new network.&nbs=
p;
You can do this already cleanly &#8211; just FIN the old path (without a DA=
TA FIN)
and bring up the new one. &nbsp;What is your proposal adding?<o:p></o:p></s=
pan></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DCalibri><span lang=
=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>[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.<o=
:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>5.1 is an
interesting problem and one that Mark led some discussion of at the last
IETF.&nbsp; As with the discussion about AVAIL_ADDR, I don&#8217;t see the =
point of
JOIN_ADDR and ADD_ADDR separations, but DEFER_ADDR (or &#8220;USE_THIS_ADDR=
!&#8221;) is an
interesting idea that I need to think about some mor</span></font><font
color=3Dnavy face=3DCalibri><span lang=3DEN-GB style=3D'font-family:Calibri=
;color:navy'>e</span></font><font
color=3D"#1f497d" face=3DCalibri><span lang=3DEN-GB style=3D'font-family:Ca=
libri;
color:#1F497D'>!<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>[G.H.] I think Mark=
 had a
more generic proxy solution in mind. The &#8220;transparent&#8221; 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 (&#8220;USE_THIS_ADDR&#8221; may indeed be cl=
earer).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Regards,<o:p><=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Alan<o:p></o:p=
></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] <b><sp=
an
style=3D'font-weight:bold'>On Behalf Of </span></b>Hampel, K Georg (K Georg=
)<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> 16 June 2011 16:03<br>
<b><span style=3D'font-weight:bold'>To:</span></b> multipathtcp@ietf.org<br=
>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Klein, Thierry E (Thierr=
y)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [multipathtcp] New =
I-D:
Enhancements to Improve the Applicability of Multipath TCP to Wireless Acce=
ss
Networks<o:p></o:p></span></font></p>

</div>

</div>

<p class=3DMsoNormal><font size=3D2 face=3D"FuturaA Bk BT"><span lang=3DEN-=
GB
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>All,<o:p></o:p></span></font></p>

<pre><font size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-famil=
y:Arial'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>We=
 have uploaded a new I-D.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'><o=
:p>&nbsp;</o:p></span></font></pre><pre><font
size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>Ti=
tle: Enhancements to Improve the Applicability of Multipath TCP to Wireless=
 Access Networks<o:p></o:p></span></font></pre>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'>Authors: Georg Hampel, Thierry=
 Klein<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<pre><font size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-famil=
y:Arial'>Filename: draft-hampel-mptcp-applicability-wireless-networks-00.tx=
t<o:p></o:p></span></font></pre>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>URL: <a
href=3D"http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-wi=
reless-networks/">http://datatracker.ietf.org/doc/draft-hampel-mptcp-applic=
ability-wireless-networks/</a><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<pre><span class=3Dmh><font size=3D2 face=3DArial><span style=3D'font-size:=
10.0pt;
font-family:Arial'>Abstract:</span></font></span><font face=3DArial><span
style=3D'font-family:Arial'><o:p></o:p></span></font></pre>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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.&nbsp; 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.&nbsp; 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.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>IMPORTANT COMMENTS: Apart from a variety of recommendati=
ons
for research, the I-D proposes the following signaling and policy enhanceme=
nts:
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>MP_SELECT option:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>The host sends this option to enforce path-selective
operation on its peer.&nbsp; 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).<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>AVAIL_ADDR/UNAVAIL_ADDR option(s):<o:p></o:p></span></fo=
nt></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>The host sends this option to inform its peer about the
availability/unavailability status of an interface referred to via an addre=
ss
id.&nbsp; 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&#8217;s interface availabili=
ty
changes. There are multiple use cases for this option (Section 3.6, Section=
 4.4
and Section 4.5).<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>DEFER_ADDR option: <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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).<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>ADD_ADDR option:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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).=
<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>JOIN_ADDR option: <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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.<o:p></o:p>=
</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>DSS insertion policy for bulk transfer: <o:p></o:p></spa=
n></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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).<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'>Please take the details from t=
he
corresponding sections of the document. Comments are welcome. Thank you.<o:=
p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'>Regards,<o:p></o:p></span></fo=
nt></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'>Georg Hampel<o:p></o:p></span>=
</font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</div>

</div>

</body>

</html>

--_000_154773479ED2314980CB638A48FC443484DC8B19USNAVSXCHMBSA2n_--

From georg.hampel@alcatel-lucent.com  Tue Jun 21 12:21:47 2011
Return-Path: <georg.hampel@alcatel-lucent.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F771F0C4B for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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)" <georg.hampel@alcatel-lucent.com>
To: Joe Touch <touch@isi.edu>, "Ford, Alan" <alan.ford@roke.co.uk>
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" <multipathtcp@ietf.org>, "Klein, Thierry E \(Thierry\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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: <touch@isi.edu>
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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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 <touch@isi.edu>
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)" <georg.hampel@alcatel-lucent.com>
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" <multipathtcp@ietf.org>, "Klein, Thierry E \(Thierry\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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: <georg.hampel@alcatel-lucent.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1296D21F84FA for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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)" <georg.hampel@alcatel-lucent.com>
To: "christoph.paasch@uclouvain.be" <christoph.paasch@uclouvain.be>, "multipathtcp@ietf.org" <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\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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: <christoph.paasch@uclouvain.be>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6C311E80D8 for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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 <christoph.paasch@uclouvain.be>
Organization: =?iso-8859-1?q?Universit=E9_Catholique_de?= Louvain
To: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com>
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" <multipathtcp@ietf.org>, "Klein, Thierry E \(Thierry\)" <thierry.klein@alcatel-lucent.com>
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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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: <georg.hampel@alcatel-lucent.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE5321F845F for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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)" <georg.hampel@alcatel-lucent.com>
To: "christoph.paasch@uclouvain.be" <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" <multipathtcp@ietf.org>, "Klein, Thierry E \(Thierry\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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: <christoph.paasch@uclouvain.be>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2FC21F8455 for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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 <christoph.paasch@uclouvain.be>
Organization: =?iso-8859-1?q?Universit=E9_Catholique_de?= Louvain
To: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com>
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" <multipathtcp@ietf.org>, "Klein, Thierry E \(Thierry\)" <thierry.klein@alcatel-lucent.com>
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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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: <georg.hampel@alcatel-lucent.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1374B21F84EC for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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)" <georg.hampel@alcatel-lucent.com>
To: "christoph.paasch@uclouvain.be" <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" <multipathtcp@ietf.org>, "Klein, Thierry E \(Thierry\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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: <yoshifumi.nishida@gmail.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5B021F85D1 for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; Mon, 27 Jun 2011 02:15:49 -0700 (PDT)
Received: by iye7 with SMTP id 7so5714474iye.31 for <multipathtcp@ietf.org>; 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: <BANLkTikkRkK-0YaZSPHZV3q48kK+pjjZKQ@mail.gmail.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
To: multipathtcp <multipathtcp@ietf.org>
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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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: <philip.eardley@bt.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3830811E807E for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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: <philip.eardley@bt.com>
To: <georg.hampel@alcatel-lucent.com>, <multipathtcp@ietf.org>
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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:"FuturaA Bk BT";}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"FuturaA Bk BT";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#606420;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:windowtext;}
span.mh
	{mso-style-name:mh;}
span.EmailStyle23
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-GB link=3Dblue vli=
nk=3D"#606420"><div class=3DWordSection1><div><p class=3DMsoNormal style=3D=
'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-fa=
mily:"Calibri","sans-serif";color:#1F497D'>Hi,<o:p></o:p></span></p><p clas=
s=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>=
<span style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=3DMsoNormal style=3D'=
mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-fam=
ily:"Calibri","sans-serif";color:#1F497D'>Firstly, the MP-PRIO message is a=
ltered to include Address ID &#8211; and (I think) a second flag meaning &#=
8216;use only this subflow&#8217; &nbsp;(not sure discussion finalised on t=
his point) <o:p></o:p></span></p><p class=3DMsoNormal style=3D'mso-margin-t=
op-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-family:"Calibri=
","sans-serif";color:#1F497D'>Secondly, the other new msgs (see below) sugg=
ested by this draft are not needed <o:p></o:p></span></p><p class=3DMsoNorm=
al><span style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>Thirdly=
, add some text something like: </span><span style=3D'font-family:"Calibri"=
,"sans-serif";color:#1F497D'>&#8220;An implementation SHOULD send DSS optio=
ns that cover multiple segments multiple times, to reduce the need for unne=
cessary buffering at the receiver.&nbsp; It is RECOMMENDED that a sender re=
peats the DSS option until a DATA ACK for some data covered by this mapping=
 is received.&#8221;<o:p></o:p></span></p><p class=3DMsoNormal style=3D'mso=
-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:9=
.0pt;font-family:"Arial","sans-serif";color:#1F497D'>Also, there may be som=
e extra /amended discussion about content-altering middleboxes (I couldn&#8=
217;t tell whether the discussion concluded on this point)<o:p></o:p></span=
></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-botto=
m-alt:auto'><span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif"=
;color:#1F497D'>Sorry where i misunderstood<o:p></o:p></span></p><p class=
=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><=
span style=3D'font-size:9.0pt;font-family:"Arial","sans-serif";color:#1F497=
D'>Thanks<o:p></o:p></span></p><p class=3DMsoNormal style=3D'mso-margin-top=
-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:9.0pt;font-f=
amily:"Arial","sans-serif";color:#1F497D'>Phil/<o:p></o:p></span></p></div>=
<p class=3DMsoNormal><span style=3D'font-family:"Calibri","sans-serif";colo=
r:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div style=3D'border:none;borde=
r-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=3DMsoNormal><=
b><span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-s=
erif"'>From:</span></b><span lang=3DEN-US style=3D'font-size:10.0pt;font-fa=
mily:"Tahoma","sans-serif"'> multipathtcp-bounces@ietf.org [mailto:multipat=
htcp-bounces@ietf.org] <b>On Behalf Of </b>Hampel, K Georg (K Georg)<br><b>=
Sent:</b> 16 June 2011 16:03<br><b>To:</b> multipathtcp@ietf.org<br><b>Cc:<=
/b> Klein, Thierry E (Thierry)<br><b>Subject:</b> [multipathtcp] New I-D: E=
nhancements to Improve the Applicability of Multipath TCP to Wireless Acces=
s Networks<o:p></o:p></span></p></div></div><p class=3DMsoNormal><o:p>&nbsp=
;</o:p></p><p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0p=
t;font-family:"Arial","sans-serif"'>All,<o:p></o:p></span></p><pre><span la=
ng=3DEN-US style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></sp=
an></pre><pre><span lang=3DEN-US style=3D'font-family:"Arial","sans-serif"'=
>We have uploaded a new I-D.<o:p></o:p></span></pre><pre><span lang=3DEN-US=
 style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></pre><=
pre><span lang=3DEN-US style=3D'font-family:"Arial","sans-serif"'>Title: En=
hancements to Improve the Applicability of Multipath TCP to Wireless Access=
 Networks<o:p></o:p></span></pre><p class=3DMsoNormal style=3D'text-autospa=
ce:none'><span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","=
sans-serif"'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal style=3D'text=
-autospace:none'><span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"=
Arial","sans-serif"'>Authors: Georg Hampel, Thierry Klein<o:p></o:p></span>=
</p><p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US s=
tyle=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p=
></span></p><pre><span lang=3DEN-US style=3D'font-family:"Arial","sans-seri=
f"'>Filename: draft-hampel-mptcp-applicability-wireless-networks-00.txt<o:p=
></o:p></span></pre><p class=3DMsoNormal><span lang=3DEN-US style=3D'font-s=
ize:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p=
 class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt;font-family=
:"Arial","sans-serif"'>URL: <a href=3D"http://datatracker.ietf.org/doc/draf=
t-hampel-mptcp-applicability-wireless-networks/">http://datatracker.ietf.or=
g/doc/draft-hampel-mptcp-applicability-wireless-networks/</a><o:p></o:p></s=
pan></p><p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:10.0pt;f=
ont-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><pre><span cla=
ss=3Dmh><span lang=3DEN-US style=3D'font-family:"Arial","sans-serif"'>Abstr=
act:</span></span><span lang=3DEN-US style=3D'font-family:"Arial","sans-ser=
if"'><o:p></o:p></span></pre><p class=3DMsoPlainText><span lang=3DEN-US sty=
le=3D'font-family:"Arial","sans-serif"'>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.&nbsp; The analysis attempts to identify use=
 cases, benefits as well as technical and functional obstacles encountered =
in the current version of the protocol.&nbsp; 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.<o:p></o:p></span></p><p class=3DMsoPlainText><spa=
n lang=3DEN-US style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p>=
</span></p><p class=3DMsoPlainText><span lang=3DEN-US style=3D'font-family:=
"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><spa=
n lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>=
IMPORTANT COMMENTS: Apart from a variety of recommendations for research, t=
he I-D proposes the following signaling and policy enhancements: <o:p></o:p=
></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><span lang=
=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&=
nbsp;</o:p></span></p><p class=3DMsoPlainText><span lang=3DEN-US style=3D'f=
ont-family:"Arial","sans-serif"'>MP_SELECT option:<o:p></o:p></span></p><p =
class=3DMsoPlainText><span lang=3DEN-US style=3D'font-family:"Arial","sans-=
serif"'>The host sends this option to enforce path-selective operation on i=
ts peer.&nbsp; 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).<o:p></o:p></span></p><p class=3DMsoPlainText><span lang=
=3DEN-US style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span=
></p><p class=3DMsoPlainText><span lang=3DEN-US style=3D'font-family:"Arial=
","sans-serif"'>AVAIL_ADDR/UNAVAIL_ADDR option(s):<o:p></o:p></span></p><p =
class=3DMsoPlainText><span lang=3DEN-US style=3D'font-family:"Arial","sans-=
serif"'>The host sends this option to inform its peer about the availabilit=
y/unavailability status of an interface referred to via an address id.&nbsp=
; 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&#8217;s interface availabili=
ty changes. There are multiple use cases for this option (Section 3.6, Sect=
ion 4.4 and Section 4.5).<o:p></o:p></span></p><p class=3DMsoPlainText><spa=
n lang=3DEN-US style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p>=
</span></p><p class=3DMsoPlainText><span lang=3DEN-US style=3D'font-family:=
"Arial","sans-serif"'>DEFER_ADDR option: <o:p></o:p></span></p><p class=3DM=
soPlainText><span lang=3DEN-US style=3D'font-family:"Arial","sans-serif"'>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).<o:p></o:p=
></span></p><p class=3DMsoPlainText><span lang=3DEN-US style=3D'font-family=
:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p class=3DMsoPlainText>=
<span lang=3DEN-US style=3D'font-family:"Arial","sans-serif"'>ADD_ADDR opti=
on:<o:p></o:p></span></p><p class=3DMsoPlainText><span lang=3DEN-US style=
=3D'font-family:"Arial","sans-serif"'>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).<o:p></o:p></span></p><p class=3DMsoPlainText><span=
 lang=3DEN-US style=3D'font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p><=
/span></p><p class=3DMsoPlainText><span lang=3DEN-US style=3D'font-family:"=
Arial","sans-serif"'>JOIN_ADDR option: <o:p></o:p></span></p><p class=3DMso=
PlainText><span lang=3DEN-US style=3D'font-family:"Arial","sans-serif"'>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.<o:p></o:p></span></p><p =
class=3DMsoPlainText><span lang=3DEN-US style=3D'font-family:"Arial","sans-=
serif"'><o:p>&nbsp;</o:p></span></p><p class=3DMsoPlainText><span lang=3DEN=
-US style=3D'font-family:"Arial","sans-serif"'>DSS insertion policy for bul=
k transfer: <o:p></o:p></span></p><p class=3DMsoPlainText><span lang=3DEN-U=
S style=3D'font-family:"Arial","sans-serif"'>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).<o:p>=
</o:p></span></p><p class=3DMsoPlainText><span lang=3DEN-US style=3D'font-f=
amily:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p class=3DMsoPlain=
Text><span lang=3DEN-US style=3D'font-family:"Arial","sans-serif"'><o:p>&nb=
sp;</o:p></span></p><p class=3DMsoNormal style=3D'text-autospace:none'><spa=
n lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>=
Please take the details from the corresponding sections of the document. Co=
mments are welcome. Thank you.<o:p></o:p></span></p><p class=3DMsoNormal st=
yle=3D'text-autospace:none'><span lang=3DEN-US style=3D'font-size:10.0pt;fo=
nt-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p class=3DMsoN=
ormal style=3D'text-autospace:none'><span lang=3DEN-US style=3D'font-size:1=
0.0pt;font-family:"Arial","sans-serif"'>Regards,<o:p></o:p></span></p><p cl=
ass=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN-US style=3D'f=
ont-size:10.0pt;font-family:"Arial","sans-serif"'>Georg Hampel<o:p></o:p></=
span></p><p class=3DMsoNormal style=3D'text-autospace:none'><span lang=3DEN=
-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;=
</o:p></span></p><p class=3DMsoPlainText><span lang=3DEN-US style=3D'font-f=
amily:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNorma=
l><span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-se=
rif"'><o:p>&nbsp;</o:p></span></p></div></body></html>=

--_000_9510D26531EF184D9017DF24659BB87F32E13B4472EMV65UKRDdoma_--

From philip.eardley@bt.com  Tue Jun 28 01:09:33 2011
Return-Path: <philip.eardley@bt.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4501221F8680 for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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: <philip.eardley@bt.com>
To: <multipathtcp@ietf.org>
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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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: <georg.hampel@alcatel-lucent.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D06E11E8112 for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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)" <georg.hampel@alcatel-lucent.com>
To: "philip.eardley@bt.com" <philip.eardley@bt.com>, "multipathtcp@ietf.org" <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\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:st=3D"&#1;" =
xmlns=3D"http://www.w3.org/TR/REC-html40"
xmlns:ns0=3D"http://schemas.microsoft.com/office/2004/12/omml">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--a:link
	{mso-style-priority:99;}
span.MSOHYPERLINK
	{mso-style-priority:99;}
a:visited
	{mso-style-priority:99;}
span.MSOHYPERLINKFOLLOWED
	{mso-style-priority:99;}
p.MSOPLAINTEXT
	{mso-style-priority:99;}
li.MSOPLAINTEXT
	{mso-style-priority:99;}
div.MSOPLAINTEXT
	{mso-style-priority:99;}
pre
	{mso-style-priority:99;}
span.HTMLPREFORMATTEDCHAR
	{mso-style-priority:99;}
span.PLAINTEXTCHAR
	{mso-style-priority:99;}

 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Trebuchet MS";
	panose-1:2 11 6 3 2 2 2 2 2 4;}
@font-face
	{font-family:"FuturaA Bk BT";
	panose-1:2 11 5 2 2 2 4 2 3 3;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"FuturaA Bk BT";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:#606420;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.HTMLPreformattedChar
	{font-family:Consolas;}
span.PlainTextChar
	{font-family:Consolas;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle24
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1450054205;
	mso-list-type:hybrid;
	mso-list-template-ids:628666940 2134916466 67698691 67698693 67698689 6769=
8691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Trebuchet MS";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3D"#606420">

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Hi Phil, all,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Georg<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>MP_SELECT: <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in;mso-list:=
l0 level1 lfo1'><![if !supportLists]><font
size=3D2 face=3D"Trebuchet MS"><span style=3D'font-size:10.0pt;font-family:=
"Trebuchet MS"'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 face=3DArial><s=
pan
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:Arial'>Alan Ford: &#8216=
;I guess we
could adapt MP_PRIO to achieve this, by having another value that means &#8=
220;use me
and me alone&#8221;.&nbsp; Although I think I need more convincing that it =
adds
value!&#8221;</span></font><font size=3D2 face=3DArial><span style=3D'font-=
size:10.0pt;
font-family:Arial'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in;mso-list:=
l0 level1 lfo1'><![if !supportLists]><font
size=3D2 face=3D"Trebuchet MS"><span style=3D'font-size:10.0pt;font-family:=
"Trebuchet MS"'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 face=3DArial><s=
pan
style=3D'font-size:10.0pt;font-family:Arial'>Georg Hampel: This would do th=
e job.
The &#8220;use me and me alone&#8221; MUST be binding though.<o:p></o:p></s=
pan></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>AVAIL/UNAVAIL_ADDRESS:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in;mso-list:=
l0 level1 lfo1'><![if !supportLists]><font
size=3D2 face=3D"Trebuchet MS"><span lang=3DEN-GB style=3D'font-size:10.0pt=
;font-family:
"Trebuchet MS"'><span style=3D'mso-list:Ignore'>-<font size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roman"'>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 face=3DArial><s=
pan
style=3D'font-size:10.0pt;font-family:Arial'>Alan Ford: &#8216;</span></fon=
t><font
size=3D2 face=3DArial><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fam=
ily:Arial'>If
we were to modify the MP_PRIO option to take an Address ID (which is someth=
ing
we&#8217;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).&nbsp; Shortcuts of a second bit to say &#8220;Do no=
t use&#8221; or
&#8220;use exclusively&#8221; could also help here.&#8217;<o:p></o:p></span=
></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in;mso-list:=
l0 level1 lfo1'><![if !supportLists]><font
size=3D2 face=3D"Trebuchet MS"><span style=3D'font-size:10.0pt;font-family:=
"Trebuchet MS"'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 face=3DArial><s=
pan
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:Arial'>Georg Hampel:&nbs=
p; MP_PRIO
with Address ID changes the semantic meaning since it refers to an address
rather than a path. I&#8217;m fine with this as long as everybody is aware =
of it. We
may have to file out the details.</span></font><font size=3D2 face=3DArial>=
<span
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in;mso-list:=
l0 level1 lfo1'><![if !supportLists]><font
size=3D2 face=3D"Trebuchet MS"><span style=3D'font-size:10.0pt;font-family:=
"Trebuchet MS"'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 face=3DArial><s=
pan
style=3D'font-size:10.0pt;font-family:Arial'>Joe Touch: &#8220;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&#8221;. Joe further recommended to cite trigtran work in this co=
ntext.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.25in'><font size=3D2 face=3DAria=
l><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>DEFER_ADDR:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in;mso-list:=
l0 level1 lfo1'><![if !supportLists]><font
size=3D2 face=3D"Trebuchet MS"><span lang=3DEN-GB style=3D'font-size:10.0pt=
;font-family:
"Trebuchet MS"'><span style=3D'mso-list:Ignore'>-<font size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roman"'>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 face=3DArial><s=
pan
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:Arial'>Alan Ford: I don&=
#8217;t see
the point of JOIN_ADDR and ADD_ADDR separations, but DEFER_ADDR (or
&#8220;USE_THIS_ADDR!&#8221;) is an interesting idea that I need to think a=
bout some more!<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in;mso-list:=
l0 level1 lfo1'><![if !supportLists]><font
size=3D2 face=3D"Trebuchet MS"><span style=3D'font-size:10.0pt;font-family:=
"Trebuchet MS"'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 face=3DArial><s=
pan
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:Arial'>Georg Hampel:
USE_THIS_ADDR instead of DEFER_ADDR is fine with me and may even be clearer=
.</span></font><font
size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'><o=
:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>ADD_ADDRESS:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in;mso-list:=
l0 level1 lfo1;
text-autospace:none'><![if !supportLists]><font size=3D2 face=3D"Trebuchet =
MS"><span
style=3D'font-size:10.0pt;font-family:"Trebuchet MS"'><span style=3D'mso-li=
st:Ignore'>-<font
size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roma=
n"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 face=3DArial><s=
pan
style=3D'font-size:10.0pt;font-family:Arial'>Christoph Paasch: &#8220;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.<o:p></o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in;mso-list:=
l0 level1 lfo1;
text-autospace:none'><![if !supportLists]><font size=3D2 face=3D"Trebuchet =
MS"><span
style=3D'font-size:10.0pt;font-family:"Trebuchet MS"'><span style=3D'mso-li=
st:Ignore'>-<font
size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roma=
n"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 face=3DArial><s=
pan
style=3D'font-size:10.0pt;font-family:Arial'>Georg Hampel: That&#8217;s rig=
ht I&#8217;ve
overseen this.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'>JOIN_ADDRESS to be separated f=
rom
ADD_ADDR: <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in;mso-list:=
l0 level1 lfo1;
text-autospace:none'><![if !supportLists]><font size=3D2 face=3D"Trebuchet =
MS"><span
style=3D'font-size:10.0pt;font-family:"Trebuchet MS"'><span style=3D'mso-li=
st:Ignore'>-<font
size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roma=
n"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 face=3DArial><s=
pan
style=3D'font-size:10.0pt;font-family:Arial'>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.<o:p></o:p></span></fon=
t></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Break before make: NOT CLARIFIED!!!<o:p></o:p></span></f=
ont></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in;mso-list:=
l0 level1 lfo1;
text-autospace:none'><![if !supportLists]><font size=3D2 face=3D"Trebuchet =
MS"><span
style=3D'font-size:10.0pt;font-family:"Trebuchet MS"'><span style=3D'mso-li=
st:Ignore'>-<font
size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roma=
n"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 face=3DArial><s=
pan
style=3D'font-size:10.0pt;font-family:Arial'>Georg Hampel: If host undergoe=
s
lower-layer BBM, it should send RST on the old interface to close state on
middleboxes.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in;mso-list:=
l0 level1 lfo1;
text-autospace:none'><![if !supportLists]><font size=3D2 face=3D"Trebuchet =
MS"><span
style=3D'font-size:10.0pt;font-family:"Trebuchet MS"'><span style=3D'mso-li=
st:Ignore'>-<font
size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roma=
n"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 face=3DArial><s=
pan
style=3D'font-size:10.0pt;font-family:Arial'>Yoshifumi Nishida: &#8220;I th=
ink L4
should be conservative to react on L2/L3 incidents, so I'm a bit skeptical
about sending RST here.&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in;mso-list:=
l0 level1 lfo1;
text-autospace:none'><![if !supportLists]><font size=3D2 face=3D"Trebuchet =
MS"><span
style=3D'font-size:10.0pt;font-family:"Trebuchet MS"'><span style=3D'mso-li=
st:Ignore'>-<font
size=3D1 face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roma=
n"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 face=3DArial><s=
pan
style=3D'font-size:10.0pt;font-family:Arial'>Olivier Bonaventure: &#8220;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).<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in;mso-list:=
l0 level1 lfo1'><![if !supportLists]><font
size=3D2 face=3D"Trebuchet MS"><span style=3D'font-size:10.0pt;font-family:=
"Trebuchet MS"'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 face=3DArial><s=
pan
style=3D'font-size:10.0pt;font-family:Arial'>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.<o:p=
></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in;mso-list:=
l0 level1 lfo1'><![if !supportLists]><font
size=3D2 face=3D"Trebuchet MS"><span style=3D'font-size:10.0pt;font-family:=
"Trebuchet MS"'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 face=3DArial><s=
pan
style=3D'font-size:10.0pt;font-family:Arial'>Georg Hampel: Christoph&#8217;=
s statement
means that the host must send RST since it cannot count on its peer to reac=
t to
FIN.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in;mso-list:=
l0 level1 lfo1'><![if !supportLists]><font
size=3D2 face=3D"Trebuchet MS"><span style=3D'font-size:10.0pt;font-family:=
"Trebuchet MS"'><span
style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times New Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 face=3DArial><s=
pan
style=3D'font-size:10.0pt;font-family:Arial'>to be continued&#8230; <o:p></=
o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>DSS insertion policy for bulk transfer: NEEDS MORE
DISCUSSION<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in;mso-list:=
l0 level1 lfo1'><![if !supportLists]><font
size=3D2 face=3D"Trebuchet MS"><span lang=3DEN-GB style=3D'font-size:10.0pt=
;font-family:
"Trebuchet MS"'><span style=3D'mso-list:Ignore'>-<font size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roman"'>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 face=3DArial><s=
pan
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:Arial'>Alan Ford: &#8220=
;An
implementation SHOULD send DSS options that cover multiple segments multipl=
e
times, to reduce the need for unnecessary buffering at the receiver.&nbsp; =
It
is RECOMMENDED that a sender repeats the DSS option until a DATA ACK for so=
me
data covered by this mapping is received.&#8221;<o:p></o:p></span></font></=
p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in;mso-list:=
l0 level1 lfo1'><![if !supportLists]><font
size=3D2 face=3D"Trebuchet MS"><span lang=3DEN-GB style=3D'font-size:10.0pt=
;font-family:
"Trebuchet MS"'><span style=3D'mso-list:Ignore'>-<font size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roman"'>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 face=3DArial><s=
pan
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:Arial'>Georg Hampel: We =
need
this to avoid an additional out-of-order queue for path-selective operation=
.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in;text-indent:-.25in;mso-list:=
l0 level1 lfo1'><![if !supportLists]><font
size=3D2 face=3D"Trebuchet MS"><span lang=3DEN-GB style=3D'font-size:10.0pt=
;font-family:
"Trebuchet MS"'><span style=3D'mso-list:Ignore'>-<font size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New Roman"'>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 face=3DArial><s=
pan
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:Arial'>Christoph Paasch =
had longer
comments on this&#8230;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span lang=3D=
EN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt;font-family:"Times=
 New Roman"'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
philip.eardley@bt.com [mailto:philip.eardley@bt.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, June 28, 2011=
 3:47
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Hampel, K Georg (K Georg=
);
multipathtcp@ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Klein, Thierry E (Thierr=
y)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [multipathtcp] =
New
I-D: Enhancements to Improve the Applicability of Multipath TCP to Wireless
Access Networks</span></font><font size=3D3 face=3D"Times New Roman"><span
style=3D'font-size:12.0pt;font-family:"Times New Roman"'><o:p></o:p></span>=
</font></p>

</div>

<p class=3DMsoNormal><font size=3D2 face=3D"FuturaA Bk BT"><span style=3D'f=
ont-size:
11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt=
:auto'><font
size=3D2 color=3D"#1f497d" face=3DCalibri><span lang=3DEN-GB style=3D'font-=
size:11.0pt;
font-family:Calibri;color:#1F497D'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt=
:auto'><font
size=3D2 color=3D"#1f497d" face=3DCalibri><span lang=3DEN-GB style=3D'font-=
size:11.0pt;
font-family:Calibri;color:#1F497D'>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.<o:p></o:p></=
span></font></p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt=
:auto'><font
size=3D2 color=3D"#1f497d" face=3DCalibri><span lang=3DEN-GB style=3D'font-=
size:11.0pt;
font-family:Calibri;color:#1F497D'>Firstly, the MP-PRIO message is altered =
to
include Address ID &#8211; and (I think) a second flag meaning &#8216;use o=
nly this
subflow&#8217; &nbsp;(not sure discussion finalised on this point) <o:p></o=
:p></span></font></p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt=
:auto'><font
size=3D2 color=3D"#1f497d" face=3DCalibri><span lang=3DEN-GB style=3D'font-=
size:11.0pt;
font-family:Calibri;color:#1F497D'>Secondly, the other new msgs (see below)
suggested by this draft are not needed <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Thirdly, add s=
ome
text something like: &#8220;An implementation SHOULD send DSS options that =
cover
multiple segments multiple times, to reduce the need for unnecessary buffer=
ing
at the receiver.&nbsp; It is RECOMMENDED that a sender repeats the DSS opti=
on
until a DATA ACK for some data covered by this mapping is received.&#8221;<=
o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt=
:auto'><font
size=3D1 color=3D"#1f497d" face=3DArial><span lang=3DEN-GB style=3D'font-si=
ze:9.0pt;
font-family:Arial;color:#1F497D'>Also, there may be some extra /amended
discussion about content-altering middleboxes (I couldn&#8217;t tell whethe=
r the
discussion concluded on this point)<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt=
:auto'><font
size=3D1 color=3D"#1f497d" face=3DArial><span lang=3DEN-GB style=3D'font-si=
ze:9.0pt;
font-family:Arial;color:#1F497D'>Sorry where i misunderstood<o:p></o:p></sp=
an></font></p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt=
:auto'><font
size=3D1 color=3D"#1f497d" face=3DArial><span lang=3DEN-GB style=3D'font-si=
ze:9.0pt;
font-family:Arial;color:#1F497D'>Thanks<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt=
:auto'><font
size=3D1 color=3D"#1f497d" face=3DArial><span lang=3DEN-GB style=3D'font-si=
ze:9.0pt;
font-family:Arial;color:#1F497D'>Phil/<o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3DCalibri><span =
lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;</o=
:p></span></font></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] <b><sp=
an
style=3D'font-weight:bold'>On Behalf Of </span></b>Hampel, K Georg (K Georg=
)<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> 16 June 2011 16:03<br>
<b><span style=3D'font-weight:bold'>To:</span></b> multipathtcp@ietf.org<br=
>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Klein, Thierry E (Thierr=
y)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [multipathtcp] New =
I-D:
Enhancements to Improve the Applicability of Multipath TCP to Wireless Acce=
ss
Networks<o:p></o:p></span></font></p>

</div>

</div>

<p class=3DMsoNormal><font size=3D2 face=3D"FuturaA Bk BT"><span lang=3DEN-=
GB
style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>All,<o:p></o:p></span></font></p>

<pre><font size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-famil=
y:Arial'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>We=
 have uploaded a new I-D.<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'><o=
:p>&nbsp;</o:p></span></font></pre><pre><font
size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'>Ti=
tle: Enhancements to Improve the Applicability of Multipath TCP to Wireless=
 Access Networks<o:p></o:p></span></font></pre>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'>Authors: Georg Hampel, Thierry=
 Klein<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<pre><font size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-famil=
y:Arial'>Filename: draft-hampel-mptcp-applicability-wireless-networks-00.tx=
t<o:p></o:p></span></font></pre>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>URL: <a
href=3D"http://datatracker.ietf.org/doc/draft-hampel-mptcp-applicability-wi=
reless-networks/">http://datatracker.ietf.org/doc/draft-hampel-mptcp-applic=
ability-wireless-networks/</a><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<pre><span class=3Dmh><font size=3D2 face=3DArial><span style=3D'font-size:=
10.0pt;
font-family:Arial'>Abstract:</span></font></span><font face=3DArial><span
style=3D'font-family:Arial'><o:p></o:p></span></font></pre>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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.&nbsp; 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.&nbsp; 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.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>IMPORTANT COMMENTS: Apart from a variety of recommendati=
ons
for research, the I-D proposes the following signaling and policy enhanceme=
nts:
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>MP_SELECT option:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>The host sends this option to enforce path-selective
operation on its peer.&nbsp; 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).<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>AVAIL_ADDR/UNAVAIL_ADDR option(s):<o:p></o:p></span></fo=
nt></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>The host sends this option to inform its peer about the
availability/unavailability status of an interface referred to via an addre=
ss
id.&nbsp; 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&#8217;s interface availabili=
ty changes.
There are multiple use cases for this option (Section 3.6, Section 4.4 and
Section 4.5).<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>DEFER_ADDR option: <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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).<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>ADD_ADDR option:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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).=
<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>JOIN_ADDR option: <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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.<o:p></o:p>=
</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>DSS insertion policy for bulk transfer: <o:p></o:p></spa=
n></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'>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).<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'>Please take the details from t=
he
corresponding sections of the document. Comments are welcome. Thank you.<o:=
p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'>Regards,<o:p></o:p></span></fo=
nt></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'>Georg Hampel<o:p></o:p></span>=
</font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<p class=3DMsoPlainText><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

--_000_154773479ED2314980CB638A48FC443484E4B0B9USNAVSXCHMBSA2n_--

From olivier.bonaventure@uclouvain.be  Wed Jun 29 00:34:19 2011
Return-Path: <olivier.bonaventure@uclouvain.be>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEEC21F86E4 for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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 <Olivier.Bonaventure@uclouvain.be>
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" <alan.ford@roke.co.uk>
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\)" <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
Reply-To: Olivier.Bonaventure@uclouvain.be
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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: <philip.eardley@bt.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507F121F8532 for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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: <philip.eardley@bt.com>
To: <multipathtcp@ietf.org>
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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-GB link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>There has been a=
 request to swap with tsvwg, so mptcp would be Fri morning (instead of Wed)=
<o:p></o:p></p><p class=3DMsoNormal>If this creates conflicts for anyone, p=
lease shout NOW<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>Thanks<o:p></o:p></p><p class=3DMsoNormal>Phil &amp; Yosh=
ifumi<o:p></o:p></p></div></body></html>=

--_000_9510D26531EF184D9017DF24659BB87F32E14C56A5EMV65UKRDdoma_--

From yoshifumi.nishida@gmail.com  Wed Jun 29 03:09:44 2011
Return-Path: <yoshifumi.nishida@gmail.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEC89E803B for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; Wed, 29 Jun 2011 03:09:42 -0700 (PDT)
Received: by iye7 with SMTP id 7so1188283iye.31 for <multipathtcp@ietf.org>; 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: <CABxaRLHO5McvBtm009NyyhYzN56bs-sfYGr91hG0wtvPjvTT5A@mail.gmail.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
To: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>, "Klein, Thierry E \(Thierry\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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) <georg.hampel@alcatel-lucent.com>:
> 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: <c.raiciu@cs.ucl.ac.uk>
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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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 <c.raiciu@cs.ucl.ac.uk>
In-Reply-To: <CABxaRLHO5McvBtm009NyyhYzN56bs-sfYGr91hG0wtvPjvTT5A@mail.gmail.com>
Date: Wed, 29 Jun 2011 10:05:43 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <C2630526-44B7-4CD8-9FD6-677E57754B4B@cs.ucl.ac.uk>
References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <CABxaRLHO5McvBtm009NyyhYzN56bs-sfYGr91hG0wtvPjvTT5A@mail.gmail.com>
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
X-Mailer: Apple Mail (2.1081)
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>, "Klein, Thierry E \(Thierry\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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) <georg.hampel@alcatel-lucent.com>:
>> 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: <georg.hampel@alcatel-lucent.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CBF21F8634 for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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)" <georg.hampel@alcatel-lucent.com>
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
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> <CABxaRLHO5McvBtm009NyyhYzN56bs-sfYGr91hG0wtvPjvTT5A@mail.gmail.com>
In-Reply-To: <CABxaRLHO5McvBtm009NyyhYzN56bs-sfYGr91hG0wtvPjvTT5A@mail.gmail.com>
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" <multipathtcp@ietf.org>, "Klein, Thierry E \(Thierry\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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) <georg.hampel@alcatel-lucent.com>:
> 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: <georg.hampel@alcatel-lucent.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDDC9E800C for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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)" <georg.hampel@alcatel-lucent.com>
To: Costin Raiciu <c.raiciu@cs.ucl.ac.uk>, Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
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> <CABxaRLHO5McvBtm009NyyhYzN56bs-sfYGr91hG0wtvPjvTT5A@mail.gmail.com> <C2630526-44B7-4CD8-9FD6-677E57754B4B@cs.ucl.ac.uk>
In-Reply-To: <C2630526-44B7-4CD8-9FD6-677E57754B4B@cs.ucl.ac.uk>
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" <multipathtcp@ietf.org>, "Klein, Thierry E \(Thierry\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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) <georg.hampel@alcatel-lucent.com>:
>> 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: <c.raiciu@cs.ucl.ac.uk>
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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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 <c.raiciu@cs.ucl.ac.uk>
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: <BF9AF115-A1A9-485B-A2F0-C25362A9FC29@cs.ucl.ac.uk>
References: <154773479ED2314980CB638A48FC443484D61294@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <9510D26531EF184D9017DF24659BB87F32E13B4472@EMV65-UKRD.domain1.systemhost.net> <154773479ED2314980CB638A48FC443484E4B0B9@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <CABxaRLHO5McvBtm009NyyhYzN56bs-sfYGr91hG0wtvPjvTT5A@mail.gmail.com> <C2630526-44B7-4CD8-9FD6-677E57754B4B@cs.ucl.ac.uk> <154773479ED2314980CB638A48FC443484E4B30C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com>
To: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com>
X-Mailer: Apple Mail (2.1081)
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>, "Klein, Thierry E \(Thierry\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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) =
<georg.hampel@alcatel-lucent.com>:
>>> 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: <georg.hampel@alcatel-lucent.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7E69E8052 for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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)" <georg.hampel@alcatel-lucent.com>
To: Costin Raiciu <c.raiciu@cs.ucl.ac.uk>
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> <CABxaRLHO5McvBtm009NyyhYzN56bs-sfYGr91hG0wtvPjvTT5A@mail.gmail.com> <C2630526-44B7-4CD8-9FD6-677E57754B4B@cs.ucl.ac.uk> <154773479ED2314980CB638A48FC443484E4B30C@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> <BF9AF115-A1A9-485B-A2F0-C25362A9FC29@cs.ucl.ac.uk>
In-Reply-To: <BF9AF115-A1A9-485B-A2F0-C25362A9FC29@cs.ucl.ac.uk>
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" <multipathtcp@ietf.org>, "Klein, Thierry E \(Thierry\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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) <georg.hampel@alcatel-lucent.com>:
>>> 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: <georg.hampel@alcatel-lucent.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B00411E8072 for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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)" <georg.hampel@alcatel-lucent.com>
To: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com>, "philip.eardley@bt.com" <philip.eardley@bt.com>, "multipathtcp@ietf.org" <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\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:st=3D"&#1;" =
xmlns=3D"http://www.w3.org/TR/REC-html40"
xmlns:ns0=3D"http://schemas.microsoft.com/office/2004/12/omml">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--a:link
	{mso-style-priority:99;}
span.MSOHYPERLINK
	{mso-style-priority:99;}
a:visited
	{mso-style-priority:99;}
span.MSOHYPERLINKFOLLOWED
	{mso-style-priority:99;}
p.MSOPLAINTEXT
	{mso-style-priority:99;}
li.MSOPLAINTEXT
	{mso-style-priority:99;}
div.MSOPLAINTEXT
	{mso-style-priority:99;}
pre
	{mso-style-priority:99;}
span.HTMLPREFORMATTEDCHAR
	{mso-style-priority:99;}
span.PLAINTEXTCHAR
	{mso-style-priority:99;}

 /* Font Definitions */
 @font-face
	{font-family:"Trebuchet MS";
	panose-1:2 11 6 3 2 2 2 2 2 4;}
@font-face
	{font-family:"FuturaA Bk BT";
	panose-1:2 11 5 2 2 2 4 2 3 3;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"FuturaA Bk BT";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:#606420;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.htmlpreformattedchar
	{font-family:Consolas;}
span.plaintextchar
	{font-family:Consolas;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle22
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle23
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle25
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1450054205;
	mso-list-type:hybrid;
	mso-list-template-ids:628666940 2134916466 67698691 67698693 67698689 6769=
8691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Trebuchet MS";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
@list l0:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3D"#606420">

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Hi all,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>I&#8217;m proposing to revise the MP_PRIO option as outlined below.=
 The
revised version tries to accommodate the issues discussed recently.<o:p></o=
:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Please comment.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Georg<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>=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<o:p></o:p></span></f=
ont></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>MP_PRIO sent by Host_A to Host_B contains the following fields:<o:p=
></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Path =3D (ADDR-ID-A, ADDR-ID-B), where <o:p></o:p></span></font></p=
>

<p class=3DMsoPlainText style=3D'text-indent:.5in'><font size=3D2 face=3D"C=
ourier New"><span
style=3D'font-size:10.0pt'>ADDR-ID-A: one of Host_A&#8217;s addresses; valu=
e 255 =3D all;
<o:p></o:p></span></font></p>

<p class=3DMsoPlainText style=3D'text-indent:.5in'><font size=3D2 face=3D"C=
ourier New"><span
style=3D'font-size:10.0pt'>ADDR-ID-B: one of Host_B&#8217;s addresses; valu=
e 255 =3D all;
<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>B-flag: (use/don&#8217;t use) path contained in this option<o:p></o=
:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>S-flag: (use only one path/use any number of paths)<o:p></o:p></spa=
n></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Operation:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>- 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.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>- 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). <o:p></o=
:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>- 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.<o:p>=
</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>- 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. <o:p></o:=
p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>- The S-flag setting &#8220;use only one path&#8221; 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.<o:p></o:p></span></font></=
p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>- 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.<o:p></o:p>=
</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>- There is no explicit confirmation of MP_PRIO. Host_A can implicit=
ly
derive MP_PRIO&#8217;s delivery from acks and/or packets arriving from Host=
 B.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Use cases/examples:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>1. Set [IP_A, IP_B] as backup path:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>MP_PRIO: path =3D [IP_A, IP_B], B =3D(don&#8217;t use), S =3D(use a=
ny number)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>2. IP_A has become unavailable:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>MP_PRIO: path =3D [IP_A, all], B =3D(don&#8217;t use), S =3D(use an=
y number)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>3. IP_A is available again:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>MP_PRIO: path=3D[IP_A, all], B =3D(use), S =3D(use any number)<o:p>=
</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>4. Use only one path, doesn&#8217;t matter which one:<o:p></o:p></s=
pan></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>MP_PRIO: path=3D[all, all], B =3D(use), S =3D(use only one path)<o:=
p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>5. Use only one path among [IP_A, IP_B] and [IP_A&#8217;, IP_B&#821=
7;]:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Add 2 MP_PRIOs into header:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>MP_PRIO: path =3D [IP_A, IP_B], B =3D(use), S =3D(either setting)<o=
:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>MP_PRIO: path =3D [IP_A&#8217;, IP_B&#8217;], B =3D(use), S =3D(use=
 only one path)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>6. Switch one selected path from [IP_A, IP_B] to [IP_A&#8217;, IP_B=
&#8217;]:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Add 2 MP_PRIOs into header:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>MP_PRIO: [IP_A, IP_B], B =3D (don&#8217;t use), S =3D (either setti=
ng)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>MP_PRIO: [IP_A&#8217;, IP_B&#8217;], B =3D (use), S =3D (use only o=
ne path)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>7. Switch one path from interface IP_A to IP_A&#8217;:<o:p></o:p></=
span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Add 2 MP_PRIOs into header:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>MP_PRIO: [IP_A, all], B =3D (don&#8217;t use), S =3D (either settin=
g)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>MP_PRIO: [IP_A&#8217;, all], B =3D (use), S =3D (use only one path)=
<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

--_000_154773479ED2314980CB638A48FC443484EBF71EUSNAVSXCHMBSA2n_--

From yoshifumi.nishida@gmail.com  Thu Jun 30 03:04:00 2011
Return-Path: <yoshifumi.nishida@gmail.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE5A21F87E7 for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; Thu, 30 Jun 2011 03:03:59 -0700 (PDT)
Received: by iwn39 with SMTP id 39so2301002iwn.31 for <multipathtcp@ietf.org>; 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: <CABxaRLF5q1Y+r-3QOL_zGc4y8H9x2Vi59WBt-wk39OxeYA9YKA@mail.gmail.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
To: "Hampel, K Georg (K Georg)" <georg.hampel@alcatel-lucent.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>, "Klein, Thierry E \(Thierry\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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) <georg.hampel@alcatel-lucent.com>:
> 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: <georg.hampel@alcatel-lucent.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9F611E80BF for <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietfa.amsl.com>; 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 <multipathtcp@ietf.org>; 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)" <georg.hampel@alcatel-lucent.com>
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
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> <CABxaRLF5q1Y+r-3QOL_zGc4y8H9x2Vi59WBt-wk39OxeYA9YKA@mail.gmail.com>
In-Reply-To: <CABxaRLF5q1Y+r-3QOL_zGc4y8H9x2Vi59WBt-wk39OxeYA9YKA@mail.gmail.com>
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" <multipathtcp@ietf.org>, "Klein, Thierry E \(Thierry\)" <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 <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multipathtcp>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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) <georg.hampel@alcatel-lucent.com>:
> 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
>
>