From christoph.paasch@uclouvain.be Fri Dec 7 03:48:35 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D06321F869A for ; Fri, 7 Dec 2012 03:48:35 -0800 (PST) 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 PPXgP+oXIFyY for ; Fri, 7 Dec 2012 03:48:35 -0800 (PST) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF8921F8635 for ; Fri, 7 Dec 2012 03:48:34 -0800 (PST) Received: from cpaasch-mac.localnet (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (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 A7F381C60EC for ; Fri, 7 Dec 2012 12:48:29 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be A7F381C60EC DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1354880909; bh=0KrXAK1LomXkWL6NRQliPIojUMmg+twph7nVpnF6v74=; h=From:To:Reply-To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=igSmJ6E4/U9xYYKE3yRHhpnEygpro4dNCNO/YtRZOHQgGoIozqsqlmvKnipoXLwoK AfvQGsO9o6mpkWndieYvYVZHW8LVdFIrsfcia9eQ9S1ExlcgfQ4C1/6yzaOdmemlvT YdI3in/h7J7w2czkZv2hHngTukK6GpEOsKOlq6XQ= From: Christoph Paasch To: MultiPath TCP - IETF WG Date: Fri, 07 Dec 2012 12:48:29 +0100 Message-ID: <1639947.RKNQ2Kqg1V@cpaasch-mac> Organization: UCLouvain User-Agent: KMail/4.9.3 (Linux/3.5.0-19-generic; KDE/4.9.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: clamav-milter 0.97.3-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: A7F381C60EC.A3EB8 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Subject: [multipathtcp] multipath-tcp.org - IETF FTP mirror X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Christoph Paasch List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 11:48:35 -0000 The Multipath TCP draft has been accepted by the IESG. It's time to use Multipath TCP for real traffic and to exchange real data. We have registered the multipath-tcp.org domain and already use it to host the website that contains all information about the reference implementation in the Linux kernel : http://www.multipath-tcp.org We have now added an ftp server to this domain : ftp://ftp.multipath-tcp.org This server runs the last build of the Linux Multipath TCP implementation and provides a mirror of the IETF website. We encourage you to use it to perform tests by using Multipath TCP. If you have installed another Multipath-TCP enabled server, let us know and we'd be happy to give you a hostname in the multipath-tcp.org domain Best regards, Christoph -- IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be UCLouvain -- From Mahesh.M@citrix.com Thu Dec 13 12:05:45 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2D721F8AA0 for ; Thu, 13 Dec 2012 12:05:45 -0800 (PST) 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=[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 6Hy9UVeVOqJm for ; Thu, 13 Dec 2012 12:05:44 -0800 (PST) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9BF21F8A96 for ; Thu, 13 Dec 2012 12:05:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,275,1355097600"; d="scan'208,217";a="601784" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 13 Dec 2012 20:05:42 +0000 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Thu, 13 Dec 2012 12:05:41 -0800 From: Mahesh M To: "multipathtcp@ietf.org" Date: Thu, 13 Dec 2012 12:05:40 -0800 Thread-Topic: Fallback mechanism Thread-Index: Ac3ZbNyQF3GxGlkPQRuCHDJBgSVykQ== Message-ID: <6E004C34C1C59E45A35B4338808BC31501301476D57F@SJCPMAILBOX01.citrite.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_6E004C34C1C59E45A35B4338808BC31501301476D57FSJCPMAILBOX_" MIME-Version: 1.0 Subject: [multipathtcp] Fallback mechanism X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 20:05:45 -0000 --_000_6E004C34C1C59E45A35B4338808BC31501301476D57FSJCPMAILBOX_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Is the infinite mapping signaling is per direction of the flow or it applie= s to both the direction? In the draft it is not clear if one end sends inf= inite mapping the other end needs to send it or not. Thinking about it, lo= oks like it is per direction and if one end sends the infinite mapping oth= er end can still continue to using regular(finite) DSS mapping. But, theore= tically after the fallback it's a single flow, both ends needs to fallback = to infinite mapping. Regards, Mahesh --_000_6E004C34C1C59E45A35B4338808BC31501301476D57FSJCPMAILBOX_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Is the = infinite mapping signaling is per direction of the flow or it applies to bo= th the direction? In the draft  it is not clear if one end sends infin= ite mapping  the other end needs to send it or not. Thinking about it,= looks like it is  per direction and if one end sends the infinite map= ping other end can still continue to using regular(finite) DSS mapping. But= , theoretically after the fallback it’s a single flow, both ends need= s to fallback to infinite mapping.

<= o:p> 

Regards,

Mahesh

 =

= --_000_6E004C34C1C59E45A35B4338808BC31501301476D57FSJCPMAILBOX_-- From nishida@sfc.wide.ad.jp Sat Dec 15 17:12:12 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64FA21F8549 for ; Sat, 15 Dec 2012 17:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 8vRR99Mirjy4 for ; Sat, 15 Dec 2012 17:12:12 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id AACBF21F8513 for ; Sat, 15 Dec 2012 17:12:11 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 8FFAD278184 for ; Sun, 16 Dec 2012 10:12:07 +0900 (JST) Received: by mail-la0-f44.google.com with SMTP id d3so3746524lah.31 for ; Sat, 15 Dec 2012 17:12:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.148.4 with SMTP id to4mr6630128lab.39.1355620325114; Sat, 15 Dec 2012 17:12:05 -0800 (PST) Received: by 10.112.142.196 with HTTP; Sat, 15 Dec 2012 17:12:04 -0800 (PST) In-Reply-To: <6E004C34C1C59E45A35B4338808BC31501301476D57F@SJCPMAILBOX01.citrite.net> References: <6E004C34C1C59E45A35B4338808BC31501301476D57F@SJCPMAILBOX01.citrite.net> Date: Sat, 15 Dec 2012 17:12:04 -0800 Message-ID: From: Yoshifumi Nishida To: Mahesh M Content-Type: multipart/alternative; boundary=e89a8f2345b3edc19304d0edf378 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Fallback mechanism X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 01:12:12 -0000 --e89a8f2345b3edc19304d0edf378 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello Mahesh, I think it's an interesting discussion point. According to the draft, it doesn't necessarily require to close all subflows except one. If other subflows are still active, it might be possible for the other side to continue using MPTCP as long as data acks come back. If we think about this kind of situations, I think infinite mapping will be one direction. Do you have any concern about using infinite mappings in one direction? When a connection has fallen back, only one subflow can send data, otherwise the receiver would not know how to reorder the data. In practice, this means that all MPTCP subflows will have to be terminated except one. Thanks, -- Yoshifumi On Thu, Dec 13, 2012 at 12:05 PM, Mahesh M wrote: > > Hi, > > > > Is the infinite mapping signaling is per direction of the flow or it applies to both the direction? In the draft it is not clear if one end sends infinite mapping the other end needs to send it or not. Thinking about it, looks like it is per direction and if one end sends the infinite mapping other end can still continue to using regular(finite) DSS mapping. But, theoretically after the fallback it=92s a single flow, both ends needs to fallback to infinite mapping. > > > > Regards, > > Mahesh > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > --e89a8f2345b3edc19304d0edf378 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello Mahesh,

I think it's an interesting discussion point.
= According to the draft, it doesn't necessarily require to close all sub= flows except one.=A0
If other subflows are still active, it might be pos= sible for the other side to continue using MPTCP as long as data acks come = back. If we think about this kind of situations, I think infinite mapping w= ill be one direction.
Do you have any concern about using infinite mappings in one direction?
=
=A0 =A0When a connection has fallen back, only one subflow can send dat= a,
=A0 =A0otherwise the receiver would not know how to reorder the data.= =A0In
=A0 =A0practice, this means that all MPTCP subflows will have to be
=A0 = =A0terminated except one.

Thanks,
--
Yoshifumi


On Thu, Dec 13, 2012 at 12:05 PM, Mahesh M <Mahesh.M@citrix.com> wrote:
>
> Hi,
>
> =A0
>
> Is the infinite mappin= g signaling is per direction of the flow or it applies to both the directio= n? In the draft =A0it is not clear if one end sends infinite mapping =A0the= other end needs to send it or not. Thinking about it, looks like it is =A0= per direction and if one end sends the infinite mapping other end can still= continue to using regular(finite) DSS mapping. But, theoretically after th= e fallback it=92s a single flow, both ends needs to fallback to infinite ma= pping.
>
> =A0
>
> Regards,
>
> Mahesh
>> =A0
>
>
> _________________________________________= ______
> multipathtcp mailing list
> multipathtcp@ietf.org
> https:/= /www.ietf.org/mailman/listinfo/multipathtcp
>
--e89a8f2345b3edc19304d0edf378-- From Mahesh.M@citrix.com Sun Dec 16 13:04:26 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F5121F8874 for ; Sun, 16 Dec 2012 13:04:26 -0800 (PST) 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=[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 N7IRSBJwGATx for ; Sun, 16 Dec 2012 13:04:24 -0800 (PST) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by ietfa.amsl.com (Postfix) with ESMTP id 881A221F860D for ; Sun, 16 Dec 2012 13:04:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,294,1355097600"; d="scan'208,217";a="841045" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 16 Dec 2012 21:04:22 +0000 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Sun, 16 Dec 2012 13:04:21 -0800 From: Mahesh M To: Yoshifumi Nishida Date: Sun, 16 Dec 2012 13:04:22 -0800 Thread-Topic: [multipathtcp] Fallback mechanism Thread-Index: Ac3bKmQk8LTY67a/QySPHMDN0fS7oAAop4Yg Message-ID: <6E004C34C1C59E45A35B4338808BC31501301476D8AD@SJCPMAILBOX01.citrite.net> References: <6E004C34C1C59E45A35B4338808BC31501301476D57F@SJCPMAILBOX01.citrite.net> In-Reply-To: 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_6E004C34C1C59E45A35B4338808BC31501301476D8ADSJCPMAILBOX_" MIME-Version: 1.0 Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Fallback mechanism X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 21:04:26 -0000 --_000_6E004C34C1C59E45A35B4338808BC31501301476D8ADSJCPMAILBOX_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I understand the reason for having a single subflow at the time of fallback= . This is exactly why both ends should fallback to infinite mapping and aft= er that they should not send any more DSS options. In the draft there two d= ifferent types of fallback one at the time of first ACK and second when the= re is a checksum issue. For the first one there is no explicit signaling fr= om the receiver but for the later one we have explicit MP_FAIL signal from = the receiver. In the explicit MP_FAIL signaling case, it contains the seque= nce number from where it wants to receive the data from the MPTCP sequence = space. If we consider a case where in both the directions data in flowing s= imultaneously, if one side fallback to infinite mapping other side has to f= allback too, but for this MP_FAIL signal has to be generated in both the di= rections so that both ends can sync up and learn the sequence from which th= ey need to start infinite mapping. Since there is no explicit signaling for the fallback mechanism at the firs= t ACK case, there needs some clarification in the draft on how/when both th= e ends will sync up on sending infinite mapping. Regards, Mahesh From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp] Sent: Saturday, December 15, 2012 5:12 PM To: Mahesh M Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Fallback mechanism Hello Mahesh, I think it's an interesting discussion point. According to the draft, it doesn't necessarily require to close all subflow= s except one. If other subflows are still active, it might be possible for the other side= to continue using MPTCP as long as data acks come back. If we think about = this kind of situations, I think infinite mapping will be one direction. Do you have any concern about using infinite mappings in one direction? When a connection has fallen back, only one subflow can send data, otherwise the receiver would not know how to reorder the data. In practice, this means that all MPTCP subflows will have to be terminated except one. Thanks, -- Yoshifumi On Thu, Dec 13, 2012 at 12:05 PM, Mahesh M > wrote: > > Hi, > > > > Is the infinite mapping signaling is per direction of the flow or it appl= ies to both the direction? In the draft it is not clear if one end sends i= nfinite mapping the other end needs to send it or not. Thinking about it, = looks like it is per direction and if one end sends the infinite mapping o= ther end can still continue to using regular(finite) DSS mapping. But, theo= retically after the fallback it's a single flow, both ends needs to fallbac= k to infinite mapping. > > > > Regards, > > Mahesh > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > --_000_6E004C34C1C59E45A35B4338808BC31501301476D8ADSJCPMAILBOX_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

 

I understand the reason for having a single subflo= w at the time of fallback. This is exactly why both ends should fallback to= infinite mapping and after that they should not send any more DSS options.= In the draft there two different types of fallback one at the time of firs= t ACK and second when there is a checksum issue. For the first one there is= no explicit signaling from the receiver but for the later one we have expl= icit MP_FAIL signal from the receiver. In the explicit MP_FAIL signaling ca= se, it contains the sequence number from where it wants to receive the data= from the MPTCP sequence space. If we consider a case where in both the dir= ections data in flowing simultaneously, if one side fallback to infinite ma= pping other side has to fallback too, but for this MP_FAIL signal has to be= generated in both the directions so that both ends can sync up and learn t= he sequence from which they need to start infinite mapping.  

Since there is no explicit signali= ng for the fallback mechanism at the first ACK case, there needs some clari= fication in the draft on how/when both the ends will sync up on sending inf= inite mapping.

 =

Regards,

=

Mahesh

 

From: Yoshifumi = Nishida [mailto:nishida@sfc.wide.ad.jp]
Sent: Saturday, December= 15, 2012 5:12 PM
To: Mahesh M
Cc: multipathtcp@ietf.or= g
Subject: Re: [multipathtcp] Fallback mechanism

 

Hello M= ahesh,

I think it's an interesting discussion point.
According t= o the draft, it doesn't necessarily require to close all subflows except on= e. 
If other subflows are still active, it might be possible for th= e other side to continue using MPTCP as long as data acks come back. If we = think about this kind of situations, I think infinite mapping will be one d= irection.
Do you have any concern about using infinite mappings in one d= irection?

   When a connection has fallen back, only one s= ubflow can send data,
   otherwise the receiver would not know= how to reorder the data.  In
   practice, this means tha= t all MPTCP subflows will have to be
   terminated except one.=

Thanks,
--
Yoshifumi



On Thu, Dec 13, 2012 at = 12:05 PM, Mahesh M <Mahesh.M@citr= ix.com> wrote:
>
> Hi,
>
>  
>> Is the infinite mapping signaling is per direction of the flow or it = applies to both the direction? In the draft  it is not clear if one en= d sends infinite mapping  the other end needs to send it or not. Think= ing about it, looks like it is  per direction and if one end sends the= infinite mapping other end can still continue to using regular(finite) DSS= mapping. But, theoretically after the fallback it’s a single flow, b= oth ends needs to fallback to infinite mapping.
>
>  
&= gt;
> Regards,
>
> Mahesh
>
>  
><= br>>
> _______________________________________________
> mul= tipathtcp mailing list
> mul= tipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp>

= --_000_6E004C34C1C59E45A35B4338808BC31501301476D8ADSJCPMAILBOX_--