From Mahesh.M@citrix.com Wed Jan 2 11:27:52 2013 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 CA91E21F8667 for ; Wed, 2 Jan 2013 11:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.098 X-Spam-Level: X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[AWL=3.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 nM+1jSTsxyLS for ; Wed, 2 Jan 2013 11:27:50 -0800 (PST) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) by ietfa.amsl.com (Postfix) with ESMTP id 470A821F865D for ; Wed, 2 Jan 2013 11:27:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,397,1355097600"; d="scan'208,217";a="2480351" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Jan 2013 19:27:49 +0000 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Wed, 2 Jan 2013 11:27:48 -0800 From: Mahesh M To: Yoshifumi Nishida Date: Wed, 2 Jan 2013 11:27:46 -0800 Thread-Topic: [multipathtcp] Fallback mechanism Thread-Index: Ac3bKmQk8LTY67a/QySPHMDN0fS7oAAop4YgA1SEtsA= Message-ID: <6E004C34C1C59E45A35B4338808BC315013014D311E3@SJCPMAILBOX01.citrite.net> References: <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_6E004C34C1C59E45A35B4338808BC315013014D311E3SJCPMAILBOX_" 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: Wed, 02 Jan 2013 19:27:52 -0000 --_000_6E004C34C1C59E45A35B4338808BC315013014D311E3SJCPMAILBOX_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Can I get some feedback on below question about fallback mechanism? This im= portant for compatibility between different implementations. Regards, Mahesh From: Mahesh M Sent: Sunday, December 16, 2012 1:04 PM To: 'Yoshifumi Nishida' Cc: multipathtcp@ietf.org Subject: RE: [multipathtcp] Fallback mechanism 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_6E004C34C1C59E45A35B4338808BC315013014D311E3SJCPMAILBOX_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

 

Can I get some feedback on below question about fa= llback mechanism? This important for compatibility between different implem= entations.

 

Regards,

Mahesh

 

From:= Mah= esh M
Sent: Sunday, December 16, 2012 1:04 PM
To: 'Yos= hifumi Nishida'
Cc: multipathtcp@ietf.org
Subject: RE: = [multipathtcp] Fallback mechanism

 

Hi,

 

I understand the reason for having a single subflow at= the time of fallback. This is exactly why both ends should fallback to inf= inite 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 first AC= K 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 explicit= MP_FAIL signal from the receiver. In the explicit MP_FAIL signaling case, = it contains the sequence number from where it wants to receive the data fro= m the MPTCP sequence space. If we consider a case where in both the directi= ons data in flowing simultaneously, if one side fallback to infinite mappin= g other side has to fallback too, but for this MP_FAIL signal has to be gen= erated in both the directions so that both ends can sync up and learn the s= equence from which they need to start infinite mapping.  

Since there is no explicit signaling f= or the fallback mechanism at the first ACK case, there needs some clarifica= tion in the draft on how/when both the ends will sync up on sending infinit= e mapping.

 

Regards,

Mahesh

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

From: Yoshifumi Nishid= a [mailto:nishida@sfc.wide.ad.jp<= /a>]
Sent: Saturday, December 15, 2012 5:12 PM
To: Mah= esh M
Cc: multipathtcp@i= etf.org
Subject: Re: [multipathtcp] Fallback mechanism

 

Hello Mahesh,

I think it's an interesting discussion point.
A= ccording to the draft, it doesn't necessarily require to close all subflows= except one. 
If other subflows are still active, it might be possi= ble for the other side to continue using MPTCP as long as data acks come ba= ck. If we think about this kind of situations, I think infinite mapping wil= l be one direction.
Do you have any concern about using infinite mapping= s in one direction?

   When a connection has fallen back, = only one subflow can send data,
   otherwise the receiver woul= d not know how to reorder the data.  In
   practice, this= means that all MPTCP subflows will have to be
   terminated e= xcept one.

Thanks,
--
Yoshifumi



On Thu, Dec 13= , 2012 at 12:05 PM, Mahesh M <Mah= esh.M@citrix.com> wrote:
>
> Hi,
>
>  <= br>>
> Is the infinite mapping signaling is per direction of the f= low 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(f= inite) DSS mapping. But, theoretically after the fallback it’s a sing= le flow, both ends needs to fallback to infinite mapping.
>
> &= nbsp;
>
> Regards,
>
> Mahesh
>
>  = ;
>
>
> _______________________________________________> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipat= htcp
>

= --_000_6E004C34C1C59E45A35B4338808BC315013014D311E3SJCPMAILBOX_-- From alanford@cisco.com Wed Jan 2 11:34:52 2013 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 C1D2821F87D4 for ; Wed, 2 Jan 2013 11:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 66Ope0m3NkVb for ; Wed, 2 Jan 2013 11:34:51 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1D721F872D for ; Wed, 2 Jan 2013 11:34:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16064; q=dns/txt; s=iport; t=1357155291; x=1358364891; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=L52y4XALpp/DsMt+s70d3QS+tmA9rGHEQjcmh5jzGtU=; b=Dff6MkBMoB8jRZl64qP1BaVAacTw8PBTNn8vcIiaorBZSUr05QZ/0kAE loXCL4K2WgrlNRfLogBbsr7DhYEpf5ArtI+IoU7HYq8wOA3BiJsGfw2ck qISEQaZAGG+iAPYTE4Hh0g+/aJyCgA6ftiCIJJ1B3ZWlo13OAYcRSrO2n U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ajk6AJWK5FCtJV2a/2dsb2JhbABFgX9KungWc4IeAQEBBAEBASpBCxIBCBEDAQEBAQodLgsUCQgBAQQBDQUIiAsMtw8EjFeDYmEDplSCdIIm X-IronPort-AV: E=Sophos;i="4.84,398,1355097600"; d="scan'208,217";a="158218508" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 02 Jan 2013 19:34:50 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r02JYoTR006605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jan 2013 19:34:50 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.240]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 13:34:50 -0600 From: "Alan Ford (alanford)" To: Mahesh M , Yoshifumi Nishida Thread-Topic: [multipathtcp] Fallback mechanism Thread-Index: Ac3bKmQk8LTY67a/QySPHMDN0fS7oAAop4YgA1SEtsAADNrpAA== Date: Wed, 2 Jan 2013 19:34:49 +0000 Message-ID: In-Reply-To: <6E004C34C1C59E45A35B4338808BC315013014D311E3@SJCPMAILBOX01.citrite.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [10.55.87.16] Content-Type: multipart/alternative; boundary="_000_B8A9B6587D9897498E7F967D5F8E987913344BC6xmbrcdx08ciscoc_" 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: Wed, 02 Jan 2013 19:34:52 -0000 --_000_B8A9B6587D9897498E7F967D5F8E987913344BC6xmbrcdx08ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Mahesh, Yes, both ends would have to send MP_FAIL in this case. The sending of a DS= S with infinite mapping is the acknowledgement signal to say that this MP_F= AIL has been received. If no DSS is received with an infinite mapping withi= n a window's worth of data, the MP_FAIL should be re-sent. An endpoint woul= d also be at liberty to close and restart this subflow (with infinite mappi= ng) if it had reason to believe its MP_FAIL was not being acted on. This is= ultimately local implementation policy and I don't see it would affect com= patibility in a big way. Regards, Alan From: Mahesh M > Date: Wed, 2 Jan 2013 11:27:46 -0800 To: Yoshifumi Nishida > Cc: "multipathtcp@ietf.org" > Subject: Re: [multipathtcp] Fallback mechanism Hi, Can I get some feedback on below question about fallback mechanism? This im= portant for compatibility between different implementations. Regards, Mahesh From: Mahesh M Sent: Sunday, December 16, 2012 1:04 PM To: 'Yoshifumi Nishida' Cc: multipathtcp@ietf.org Subject: RE: [multipathtcp] Fallback mechanism 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=92s a single flow, both ends needs to fallb= ack to infinite mapping. > > > > Regards, > > Mahesh > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > _______________________________________________ multipathtcp mailing list m= ultipathtcp@ietf.org https://www.ietf.org/mai= lman/listinfo/multipathtcp --_000_B8A9B6587D9897498E7F967D5F8E987913344BC6xmbrcdx08ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Mahesh,

Yes, both ends would have to send MP_FAIL in this case. The sendi= ng of a DSS with infinite mapping is the acknowledgement signal to say that= this MP_FAIL has been received. If no DSS is received with an infinite map= ping within a window's worth of data, the MP_FAIL should be re-sent. An endpoint would also be at liberty to clo= se and restart this subflow (with infinite mapping) if it had reason to bel= ieve its MP_FAIL was not being acted on. This is ultimately local implement= ation policy and I don't see it would affect compatibility in a big way.

Regards,
Alan

From: Mahesh M <Mahesh.M@citrix.com>
Date: Wed, 2 Jan 2013 11:27:46 -080= 0
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] Fallbac= k mechanism

Hi,

 

Can I get some feedback on below q= uestion about fallback mechanism? This important for compatibility between = different implementations.

 

Regards,

Mahesh

 

From: Mahesh M
Sent: Sunday, December 16, 2012 1:04 PM
To: 'Yoshifumi Nishida'
Cc: multipathtcp@ietf.org
Subject: RE: [multipathtcp] Fallback mechanism

 

Hi,

 

I understand the reason for having= a single subflow at the time of fallback. This is exactly why both ends sh= ould fallback to infinite mapping and after that they should not send any more DSS options. In the draft there t= wo different types of fallback one at the time of first ACK and second when= there is a checksum issue. For the first one there is no explicit signalin= g from the receiver but for the later one we have explicit MP_FAIL signal from the receiver. In the explic= it MP_FAIL signaling case, it contains the sequence number from where it wa= nts to receive the data from the MPTCP sequence space. If we consider a cas= e where in both the directions data in flowing simultaneously, if one side fallback to infinite mapping other = side has to fallback too, but for this MP_FAIL signal has to be generated i= n both the directions so that both ends can sync up and learn the 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 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 d= ata,
   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 <Mahesh.M@citrix.com> wrote:
>
> Hi,
>
>  
>
> Is the infinite mapping signaling is per direction of the flow or it a= pplies 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. Thinki= ng 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
>

_______________________________________________ multipathtcp mailing list <= a href=3D"mailto:multipathtcp@ietf.org"> multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp --_000_B8A9B6587D9897498E7F967D5F8E987913344BC6xmbrcdx08ciscoc_-- From Mahesh.M@citrix.com Wed Jan 2 11:44:44 2013 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 D142921F8848 for ; Wed, 2 Jan 2013 11:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.265 X-Spam-Level: X-Spam-Status: No, score=-8.265 tagged_above=-999 required=5 tests=[AWL=2.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 QHyF8C84IpUU for ; Wed, 2 Jan 2013 11:44:41 -0800 (PST) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) by ietfa.amsl.com (Postfix) with ESMTP id 577F221F879E for ; Wed, 2 Jan 2013 11:44:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,398,1355097600"; d="scan'208,217";a="2481891" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 02 Jan 2013 19:44:40 +0000 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Wed, 2 Jan 2013 11:44:39 -0800 From: Mahesh M To: "Alan Ford (alanford)" , Yoshifumi Nishida Date: Wed, 2 Jan 2013 11:44:37 -0800 Thread-Topic: [multipathtcp] Fallback mechanism Thread-Index: Ac3bKmQk8LTY67a/QySPHMDN0fS7oAAop4YgA1SEtsAADNrpAAAMSofQ Message-ID: <6E004C34C1C59E45A35B4338808BC315013014D311F4@SJCPMAILBOX01.citrite.net> References: <6E004C34C1C59E45A35B4338808BC315013014D311E3@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_6E004C34C1C59E45A35B4338808BC315013014D311F4SJCPMAILBOX_" 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: Wed, 02 Jan 2013 19:44:44 -0000 --_000_6E004C34C1C59E45A35B4338808BC315013014D311F4SJCPMAILBOX_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I did not find any mention in the draft that the end receiving MP_FAIL also= needs to send MP_FAIL after sending infinite mapping. If it is there let m= e know. If draft does not make in mandatory then it can create incompatibil= ity. Regards, Mahesh From: Alan Ford (alanford) [mailto:alanford@cisco.com] Sent: Wednesday, January 02, 2013 11:35 AM To: Mahesh M; Yoshifumi Nishida Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Fallback mechanism Hi Mahesh, Yes, both ends would have to send MP_FAIL in this case. The sending of a DS= S with infinite mapping is the acknowledgement signal to say that this MP_F= AIL has been received. If no DSS is received with an infinite mapping withi= n a window's worth of data, the MP_FAIL should be re-sent. An endpoint woul= d also be at liberty to close and restart this subflow (with infinite mappi= ng) if it had reason to believe its MP_FAIL was not being acted on. This is= ultimately local implementation policy and I don't see it would affect com= patibility in a big way. Regards, Alan From: Mahesh M > Date: Wed, 2 Jan 2013 11:27:46 -0800 To: Yoshifumi Nishida > Cc: "multipathtcp@ietf.org" > Subject: Re: [multipathtcp] Fallback mechanism Hi, Can I get some feedback on below question about fallback mechanism? This im= portant for compatibility between different implementations. Regards, Mahesh From: Mahesh M Sent: Sunday, December 16, 2012 1:04 PM To: 'Yoshifumi Nishida' Cc: multipathtcp@ietf.org Subject: RE: [multipathtcp] Fallback mechanism 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 > _______________________________________________ multipathtcp mailing list m= ultipathtcp@ietf.org https://www.ietf.org/mai= lman/listinfo/multipathtcp --_000_6E004C34C1C59E45A35B4338808BC315013014D311F4SJCPMAILBOX_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

 

I did not find any mention in the draft that the e= nd receiving MP_FAIL also needs to send MP_FAIL after sending infinite mapp= ing. If it is there let me know. If draft does not make in mandatory then i= t can create incompatibility.

 

Regards,

Mahesh

 

From: Alan Ford (alanford) [mailto:alanford@cisco.com]
Se= nt: Wednesday, January 02, 2013 11:35 AM
To: Mahesh M; Yoshif= umi Nishida
Cc: multipathtcp@ietf.org
Subject: Re: [mul= tipathtcp] Fallback mechanism

 

Hi Mahesh= ,

 

Yes, both ends would have= to send MP_FAIL in this case. The sending of a DSS with infinite mapp= ing is the acknowledgement signal to say that this MP_FAIL has been receive= d. If no DSS is received with an infinite mapping within a window's worth o= f data, the MP_FAIL should be re-sent. An endpoint would also be at liberty= to close and restart this subflow (with infinite mapping) if it had reason= to believe its MP_FAIL was not being acted on. This is ultimately local im= plementation policy and I don't see it would affect compatibility in a big = way.

 <= /o:p>

Regards,

Alan

 

From: Mahesh M <Mahesh.M@citrix.com>
Date: = Wed, 2 Jan 2013 11:27:46 -0800
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
= Cc: "multipathtcp@ietf.or= g" <multipathtcp@ietf.= org>
Subject: Re: [multipathtcp] Fallback mechanism

 

Hi,

 =

Can I get some feedback on below question about fallback mechanism? This= important for compatibility between different implementations.

&n= bsp;

Regards,=

Mahesh

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:blac= k'>From: Mahesh M
Sent: Sunday, December 16, 2012= 1:04 PM
To: 'Yoshifumi Nishida'
Cc: multipathtcp@ietf.org
Subject: RE: [mu= ltipathtcp] Fallback mechanism

&n= bsp;

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 after that they should not send any more DSS options. In the draft the= re two different types of fallback one at the time of first ACK and second = when there is a checksum issue. For the first one there is no explicit sign= aling from the receiver but for the later one we have explicit MP_FAIL sign= al from the receiver. In the explicit MP_FAIL signaling case, it contains t= he sequence number from where it wants to receive the data from the MPTCP s= equence space. If we consider a case where in both the directions data in f= lowing simultaneously, if one side fallback to infinite mapping other side = has to fallback too, but for this MP_FAIL signal has to be generated in bot= h the directions so that both ends can sync up and learn the sequence from = which they need to start infinite mapping.  

Since there is n= o explicit signaling for the fallback mechanism at the first ACK case, ther= e needs some clarification in the draft on how/when both the 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: Mahes= h M
Cc: multipathtcp@iet= f.org
Subject: Re: [multipathtcp] Fallback mechanism

 

Hello Mahesh,

I think it's an interesting di= scussion point.
According to the draft, it doesn't necessarily require = to close all subflows except one. 
If other subflows are still acti= ve, 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 u= sing infinite mappings in one direction?

   When a connect= ion has fallen back, only one subflow can send data,
   otherw= ise the receiver would not know how to reorder the data.  In
 =  practice, this means that all MPTCP subflows will have to be
&nbs= p;  terminated except one.

Thanks,
--
Yoshifumi

<= br>
On Thu, Dec 13, 2012 at 12:05 PM, Mahesh M <Mahesh.M@citrix.com> wrote:
>
> Hi,>
>  
>
> Is the infinite mapping signaling is p= er 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 dir= ection and if one end sends the infinite mapping other end can still contin= ue to using regular(finite) DSS mapping. But, theoretically after the fallb= ack it’s a single flow, both ends needs to fallback to infinite mappi= ng.
>
>  
>
> Regards,
>
> Mahesh<= br>>
>  
>
>
> ____________________________= ___________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mail= man/listinfo/multipathtcp
>

_______________________________________________ multi= pathtcp mailing list multipathtcp@= ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp <= /p>

= --_000_6E004C34C1C59E45A35B4338808BC315013014D311F4SJCPMAILBOX_-- From alanford@cisco.com Wed Jan 2 11:49:37 2013 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 0A5D521F8873 for ; Wed, 2 Jan 2013 11:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 kX2YxTyKGbNu for ; Wed, 2 Jan 2013 11:49:35 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 62F5021F8871 for ; Wed, 2 Jan 2013 11:49:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23667; q=dns/txt; s=iport; t=1357156174; x=1358365774; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=zTpLKfrwjej1Lf4J+KDjF5VlqrhkjuwW9xdhd99Y9oI=; b=EagcuEi54Jt6yKRo3NlUcEMgQR46CdUHeDmp65cFtEIaGqD/62hhJ6Cl +3q7UVKrL0gdLfE1abgBzPunoGPtcYdPzVwm04n1f5tD/SEK2Yehc2HFj iW3kSZM3FyDHncvGLXoIx5QQOwg/+qWuLagxRz1EOytlZpAOHqbw/nHFu o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ajo6AA2O5FCtJV2c/2dsb2JhbABFgX9KungWc4IeAQEBBAEBASpBCxIBCBEDAQEBAQoWBy4LFAkIAQEEAQ0FCIgLDLcXBIxXg2JhA6ZUgnSCJg X-IronPort-AV: E=Sophos;i="4.84,398,1355097600"; d="scan'208,217";a="158180377" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 02 Jan 2013 19:49:33 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r02JnXHx013019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jan 2013 19:49:33 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.240]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 13:49:33 -0600 From: "Alan Ford (alanford)" To: Mahesh M , Yoshifumi Nishida Thread-Topic: [multipathtcp] Fallback mechanism Thread-Index: Ac3bKmQk8LTY67a/QySPHMDN0fS7oAAop4YgA1SEtsAADNrpAAAMSofQ//+hzgA= Date: Wed, 2 Jan 2013 19:49:33 +0000 Message-ID: In-Reply-To: <6E004C34C1C59E45A35B4338808BC315013014D311F4@SJCPMAILBOX01.citrite.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [10.55.87.16] Content-Type: multipart/alternative; boundary="_000_B8A9B6587D9897498E7F967D5F8E987913344C21xmbrcdx08ciscoc_" 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: Wed, 02 Jan 2013 19:49:37 -0000 --_000_B8A9B6587D9897498E7F967D5F8E987913344C21xmbrcdx08ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable No, you do not need to send an MP_FAIL on receipt of an MP_FAIL. I thought = the case you described below referred to when both ends detected a failure = at the same time. Reading again, I see you mean that you need both ends to fall back if one h= as signalled it. I don't see there any technical reason why you could not have asymmetric pa= ths deployed, with only one direction fallen back, but in reality I would e= xpect both ends to fallback. Whilst it could could increase complexity to c= ope with this, it does not seem necessary to prohibit it. A simple implemen= tation that could not cope with asymmetry in the directions could choose to= send MP_FAIL on receipt of MP_FAIL and thus would be safe. Regards, Alan From: Mahesh M > Date: Wed, 2 Jan 2013 11:44:37 -0800 To: Alan Ford >, Yoshifumi Ni= shida > Cc: "multipathtcp@ietf.org" > Subject: RE: [multipathtcp] Fallback mechanism Hi, I did not find any mention in the draft that the end receiving MP_FAIL also= needs to send MP_FAIL after sending infinite mapping. If it is there let m= e know. If draft does not make in mandatory then it can create incompatibil= ity. Regards, Mahesh From: Alan Ford (alanford) [mailto:alanford@cisco.com] Sent: Wednesday, January 02, 2013 11:35 AM To: Mahesh M; Yoshifumi Nishida Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Fallback mechanism Hi Mahesh, Yes, both ends would have to send MP_FAIL in this case. The sending of a DS= S with infinite mapping is the acknowledgement signal to say that this MP_F= AIL has been received. If no DSS is received with an infinite mapping withi= n a window's worth of data, the MP_FAIL should be re-sent. An endpoint woul= d also be at liberty to close and restart this subflow (with infinite mappi= ng) if it had reason to believe its MP_FAIL was not being acted on. This is= ultimately local implementation policy and I don't see it would affect com= patibility in a big way. Regards, Alan From: Mahesh M > Date: Wed, 2 Jan 2013 11:27:46 -0800 To: Yoshifumi Nishida > Cc: "multipathtcp@ietf.org" > Subject: Re: [multipathtcp] Fallback mechanism Hi, Can I get some feedback on below question about fallback mechanism? This im= portant for compatibility between different implementations. Regards, Mahesh From: Mahesh M Sent: Sunday, December 16, 2012 1:04 PM To: 'Yoshifumi Nishida' Cc: multipathtcp@ietf.org Subject: RE: [multipathtcp] Fallback mechanism 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=92s a single flow, both ends needs to fallb= ack to infinite mapping. > > > > Regards, > > Mahesh > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > _______________________________________________ multipathtcp mailing list m= ultipathtcp@ietf.org https://www.ietf.org/mai= lman/listinfo/multipathtcp --_000_B8A9B6587D9897498E7F967D5F8E987913344C21xmbrcdx08ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <934E877AC6B9BD4AA63CE660B1CB2AF5@cisco.com> Content-Transfer-Encoding: quoted-printable
No, you do not need to send an MP_FAIL on receipt of an MP_FAIL. I tho= ught the case you described below referred to when both ends detected a fai= lure at the same time.

Reading again, I see you mean that you need both ends to fall back if = one has signalled it.

I don't see there any technical reason why you could not have asymmetr= ic paths deployed, with only one direction fallen back, but in reality I wo= uld expect both ends to fallback. Whilst it could could increase complexity= to cope with this, it does not seem necessary to prohibit it. A simple implementation that could not cope= with asymmetry in the directions could choose to send MP_FAIL on receipt o= f MP_FAIL and thus would be safe.

Regards,
Alan

From: Mahesh M <Mahesh.M@citrix.com>
Date: Wed, 2 Jan 2013 11:44:37 -080= 0
To: Alan Ford <alanford@cisco.com>, Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: RE: [multipathtcp] Fallbac= k mechanism

Hi,

 

I did not find any mention in the = draft that the end receiving MP_FAIL also needs to send MP_FAIL after sendi= ng infinite mapping. If it is there let me know. If draft does not make in mandatory then it can create incomp= atibility.

 

Regards,

Mahesh

 

From: Alan Ford (alanford) [mailto:alanford@cisco.com]
Sent: Wednesday, January 02, 2013 11:35 AM
To: Mahesh M; Yoshifumi Nishida
Cc: multipathtcp@ietf.org
Subject: Re: [multipathtcp] Fallback mechanism

 

Hi Mahesh,

 

Yes, both ends would have to send MP_FAIL i= n this case. The sending of a DSS with infinite mapping is the acknowl= edgement signal to say that this MP_FAIL has been received. If no DSS is received with an infinite mapping within a= window's worth of data, the MP_FAIL should be re-sent. An endpoint would a= lso be at liberty to close and restart this subflow (with infinite mapping)= if it had reason to believe its MP_FAIL was not being acted on. This is ultimately local implementation po= licy and I don't see it would affect compatibility in a big way.=

 

Regards,

Alan

 

From: Mahesh M <Mahes= h.M@citrix.com>
Date: Wed, 2 Jan 2013 11:27:46 -0800
To: Yoshifumi Nishida <= nishida@sfc.wide.ad.jp>
Cc: "multipathtcp@ietf= .org" <multipathtcp@ie= tf.org>
Subject: Re: [multipathtcp] Fallback mechanism

 

Hi,

 

Can I get some feedback on below q= uestion about fallback mechanism? This important for compatibility between = different implementations.

 

Regards,

Mahesh

 

From: Mahesh M
Sent: Sunday, December 16, 2012 1:04 PM
To: 'Yoshifumi Nishida'
Cc: multipathtcp@ietf.org
Subject: RE: [multipathtcp] Fallback mechanism

 =

Hi,

 

I understand the reason for having= a single subflow at the time of fallback. This is exactly why both ends sh= ould fallback to infinite mapping and after that they should not send any more DSS options. In the draft there t= wo different types of fallback one at the time of first ACK and second when= there is a checksum issue. For the first one there is no explicit signalin= g from the receiver but for the later one we have explicit MP_FAIL signal from the receiver. In the explic= it MP_FAIL signaling case, it contains the sequence number from where it wa= nts to receive the data from the MPTCP sequence space. If we consider a cas= e where in both the directions data in flowing simultaneously, if one side fallback to infinite mapping other = side has to fallback too, but for this MP_FAIL signal has to be generated i= n both the directions so that both ends can sync up and learn the 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 infinite mapping.

 

Regards,

Mahesh

 

From: Yoshifumi Nishida [<= a href=3D"mailto:nishida@sfc.wide.ad.jp">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 d= ata,
   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 <Mahesh.M@citrix.com> wrote:
>
> Hi,
>
>  
>
> Is the infinite mapping signaling is per direction of the flow or it a= pplies 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. Thinki= ng 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
>

___________________________________________= ____ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp

--_000_B8A9B6587D9897498E7F967D5F8E987913344C21xmbrcdx08ciscoc_-- From nishida@sfc.wide.ad.jp Wed Jan 2 21:53:34 2013 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 8974C21F8804 for ; Wed, 2 Jan 2013 21:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.916 X-Spam-Level: X-Spam-Status: No, score=-101.916 tagged_above=-999 required=5 tests=[AWL=0.060, 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 awCgntmb6Dsh for ; Wed, 2 Jan 2013 21:53:33 -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 AB91821F8792 for ; Wed, 2 Jan 2013 21:53:32 -0800 (PST) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 35A442780C8 for ; Thu, 3 Jan 2013 14:53:27 +0900 (JST) Received: by mail-la0-f46.google.com with SMTP id fq13so7345876lab.33 for ; Wed, 02 Jan 2013 21:53:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.16.203 with SMTP id i11mr19577169lbd.135.1357192405717; Wed, 02 Jan 2013 21:53:25 -0800 (PST) Received: by 10.112.142.196 with HTTP; Wed, 2 Jan 2013 21:53:25 -0800 (PST) In-Reply-To: <6E004C34C1C59E45A35B4338808BC315013014D311F4@SJCPMAILBOX01.citrite.net> References: <6E004C34C1C59E45A35B4338808BC315013014D311E3@SJCPMAILBOX01.citrite.net> <6E004C34C1C59E45A35B4338808BC315013014D311F4@SJCPMAILBOX01.citrite.net> Date: Wed, 2 Jan 2013 21:53:25 -0800 Message-ID: From: Yoshifumi Nishida To: Mahesh M Content-Type: multipart/alternative; boundary=f46d0401f99d3c12df04d25bfb9c 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: Thu, 03 Jan 2013 05:53:34 -0000 --f46d0401f99d3c12df04d25bfb9c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Mahesh, I can imagine most of implementations will fallback in both directions and I think it is totally fine since it's not violating the spec at all. But, I don't see a strong reason to update the spec to make this mandatory. Are there potential risks for one way infinite mapping? Thanks, -- Yoshifumi On Wed, Jan 2, 2013 at 11:44 AM, Mahesh M wrote: > Hi,**** > > ** ** > > I did not find any mention in the draft that the end receiving MP_FAIL > also needs to send MP_FAIL after sending infinite mapping. If it is there > let me know. If draft does not make in mandatory then it can create > incompatibility.**** > > ** ** > > Regards,**** > > Mahesh**** > > ** ** > > *From:* Alan Ford (alanford) [mailto:alanford@cisco.com] > *Sent:* Wednesday, January 02, 2013 11:35 AM > *To:* Mahesh M; Yoshifumi Nishida > *Cc:* multipathtcp@ietf.org > *Subject:* Re: [multipathtcp] Fallback mechanism**** > > ** ** > > Hi Mahesh,**** > > ** ** > > Yes, both ends would have to send MP_FAIL in this case. The sending of a > DSS with infinite mapping is the acknowledgement signal to say that this > MP_FAIL has been received. If no DSS is received with an infinite mapping > within a window's worth of data, the MP_FAIL should be re-sent. An endpoi= nt > would also be at liberty to close and restart this subflow (with infinite > mapping) if it had reason to believe its MP_FAIL was not being acted on. > This is ultimately local implementation policy and I don't see it would > affect compatibility in a big way.**** > > ** ** > > Regards,**** > > Alan**** > > ** ** > > *From: *Mahesh M > *Date: *Wed, 2 Jan 2013 11:27:46 -0800 > *To: *Yoshifumi Nishida > *Cc: *"multipathtcp@ietf.org" > *Subject: *Re: [multipathtcp] Fallback mechanism**** > > ** ** > > Hi,**** > > **** > > Can I get some feedback on below question about fallback mechanism? This > important for compatibility between different implementations.**** > > **** > > Regards,**** > > Mahesh**** > > **** > > *From:* Mahesh M > *Sent:* Sunday, December 16, 2012 1:04 PM > *To:* 'Yoshifumi Nishida' > *Cc:* multipathtcp@ietf.org > *Subject:* RE: [multipathtcp] Fallback mechanism**** > > **** > > 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 mappi= ng > 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 first 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 explic= it > MP_FAIL signal from the receiver. In the explicit MP_FAIL signaling case, > 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 > directions data in flowing simultaneously, if one side fallback to infini= te > mapping other side has to fallback too, but for this MP_FAIL signal has t= o > be generated in both the directions so that both ends can sync up and lea= rn > the sequence from which they need to start infinite mapping. **** > > Since there is no explicit signaling for the fallback mechanism at the > first ACK case, there needs some clarification in the draft on how/when > both the 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 > 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 infini= te > mapping other end can still continue to using regular(finite) DSS mapping= . > But, theoretically after the fallback it=92s a single flow, both ends nee= ds > to fallback to infinite mapping. > > > > > > > > Regards, > > > > Mahesh > > > > > > > > > > _______________________________________________ > > 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 = * > *** > --f46d0401f99d3c12df04d25bfb9c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Mahesh,

I can imagine most of implementations will fa= llback in both directions and I think it is totally fine since it's not= violating the spec at all.
But, I don't see a strong reason = to update the spec to make this mandatory.
Are there potential risks for one way infinite mapping?=A0
<= br>
Thanks,
--
Yoshifumi

On Wed, Jan 2, 2013 at 11:44 AM, Mahesh M <Mahesh.M= @citrix.com> wrote:

Hi,=

=A0<= /p>

I did not find any men= tion in the draft that the end receiving MP_FAIL also needs to send MP_FAIL= after sending infinite mapping. If it is there let me know. If draft does = not make in mandatory then it can create incompatibility.

=A0<= /p>

Regards,=

Mahesh

=A0

From: Alan Ford (alanford) [mailto:alanford@cisco.com]
Sent: Wednesday, January 02, 2013 11:35 AM
To: Mahesh M; Y= oshifumi Nishida
Cc: multipathtcp@ietf.org
Subject: Re: [multipatht= cp] Fallback mechanism

=A0=

Hi Mahesh,<= /span>

=A0

=

Yes, both ends would have to= send MP_FAIL in this case.=A0The sending of a DSS with infinite mapping is= the acknowledgement signal to say that this MP_FAIL has been received. If = no DSS is received with an infinite mapping within a window's worth of = data, the MP_FAIL should be re-sent. An endpoint would also be at liberty t= o close and restart this subflow (with infinite mapping) if it had reason t= o believe its MP_FAIL was not being acted on. This is ultimately local impl= ementation policy and I don't see it would affect compatibility in a bi= g way.

=A0

=

Regards,

Alan

=A0

From: Mahesh M <Mahesh.M@citrix.com>
Date: Wed, 2 Jan 2013 11:27:46 -0800
To: Yoshifumi Nishida= <nishida@sf= c.wide.ad.jp>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org><= br> Subject: Re: [multipathtcp] Fallback mechanism<= /p>

=A0<= /p>

Hi,

=A0

Can I get some feedback o= n below question about fallback mechanism? This important for compatibility= between different implementations.=

=A0=

Reg= ards,

Mahesh=

= =A0

From: Mahesh M
Sent: Sunday, December 16, 2012 1:04 PM
To: 'Yoshifumi= Nishida'
Cc: multipathtcp@ietf.org
Subject: RE: [multipathtcp]= Fallback mechanism

=A0

=

Hi,=

=A0=

I u= nderstand the reason for having a single subflow at the time of fallback. T= his 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 diff= erent types of fallback one at the time of first 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 explicit MP_FAIL signal from the= receiver. In the explicit MP_FAIL signaling case, it contains the sequence= number from where it wants to receive the data from the MPTCP sequence spa= ce. If we consider a case where in both the directions data in flowing simu= ltaneously, if one side fallback to infinite mapping other side has to fall= back too, but for this MP_FAIL signal has to be generated in both the direc= tions so that both ends can sync up and learn the sequence from which they = need to start infinite mapping. =A0=

Since there is no explici= t signaling for the fallback mechanism at the first ACK case, there needs s= ome clarification in the draft on how/when both the ends will sync up on se= nding infinite mapping.

=A0=

Reg= ards,

Mahesh

=A0

From: Yoshifum= i Nishida [mail= to:nishida@sfc.wide.ad.jp]
Sent: Saturday, December 15, 2012 5:12 PM
To: Mahesh M
= Cc: multi= pathtcp@ietf.org
Subject: Re: [multipathtcp] Fallback mechani= sm

=A0

Hello Mahesh,

I think it's an interesting= discussion point.
According to the draft, it doesn't necessarily r= equire to close all subflows except one.=A0
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?
=
=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
><= u>

___= ____________________________________________ multipathtcp mailing list multipathtcp@ietf.or= g https://www.ietf.org/mailman/listinfo/multipathtcp <= u>


--f46d0401f99d3c12df04d25bfb9c-- From waehlisch@ieee.org Wed Jan 9 12:12:39 2013 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 9216021F884F for ; Wed, 9 Jan 2013 12:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 MuzUz4gode9D for ; Wed, 9 Jan 2013 12:12:38 -0800 (PST) Received: from mail1.rz.htw-berlin.de (mail1.rz.htw-berlin.de [141.45.10.101]) by ietfa.amsl.com (Postfix) with ESMTP id A1B9C21F8569 for ; Wed, 9 Jan 2013 12:12:38 -0800 (PST) Envelope-to: multipathtcp@ietf.org Received: from g231108194.adsl.alicedsl.de ([92.231.108.194] helo=mw-PC.fritz.box) by mail1.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Tt20q-000HRn-NQ; Wed, 09 Jan 2013 21:12:37 +0100 Date: Wed, 9 Jan 2013 21:12:31 +0100 From: Matthias Waehlisch To: multipathtcp@ietf.org Message-ID: X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multipathtcp@ietf.org Cc: Raphael Wutzke Subject: [multipathtcp] MPTCP Port for Google Nexus S X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 20:12:39 -0000 Hi folks, we ported UCLouvain MPTCP implementation to Android 4.1.2. If you are interested in running MPTCP at Google Nexus S, please, have a look at https://github.com/mptcp-nexus/android The complete package (https://github.com/mptcp-nexus/) includes: * A modified Android Connection Manager, which enables 3G and WiFi in parallel (in android_framework_base). * A modified Network Daemon, which automatically configures routes for both interfaces (in android_system_netd). * A modified iproute2 package to enable the MPTCPControl app to support MPTCP specific commands (in android_external_iproute2). Many thanks to Christoph for support! Cheers on behalf of the team matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From nishida@sfc.wide.ad.jp Thu Jan 10 21:52:14 2013 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 2C8FB21F872C for ; Thu, 10 Jan 2013 21:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 WUaybYT65SNp for ; Thu, 10 Jan 2013 21:52:09 -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 494F421F871E for ; Thu, 10 Jan 2013 21:52:06 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 7320E278197 for ; Fri, 11 Jan 2013 14:52:04 +0900 (JST) Received: by mail-lb0-f169.google.com with SMTP id gk1so1058476lbb.28 for ; Thu, 10 Jan 2013 21:52:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.148.164 with SMTP id tt4mr31273898lab.28.1357883521798; Thu, 10 Jan 2013 21:52:01 -0800 (PST) Received: by 10.112.142.196 with HTTP; Thu, 10 Jan 2013 21:52:01 -0800 (PST) Date: Thu, 10 Jan 2013 21:52:01 -0800 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] WG meeting in Orlando X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 05:52:14 -0000 Hello, Phil and I are thinking about the WG meeting in Orlando. We're thinking that having a hour or so slot to discuss the recent updates of activities would be good. Also, if you have some topics to be discussed at the meeting, please let us know. Thanks, -- Yoshifumi & Phil From wwwrun@rfc-editor.org Thu Jan 17 11:39:57 2013 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 0C1E321F892D; Thu, 17 Jan 2013 11:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.345 X-Spam-Level: X-Spam-Status: No, score=-102.345 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, NO_RELAYS=-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 ne2l-gXbR2GM; Thu, 17 Jan 2013 11:39:51 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id C7FCB21F8919; Thu, 17 Jan 2013 11:39:51 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 51E50B1E00B; Thu, 17 Jan 2013 11:28:59 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130117192859.51E50B1E00B@rfc-editor.org> Date: Thu, 17 Jan 2013 11:28:59 -0800 (PST) Cc: multipathtcp@ietf.org, rfc-editor@rfc-editor.org Subject: [multipathtcp] RFC 6824 on TCP Extensions for Multipath Operation with Multiple Addresses 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, 17 Jan 2013 19:39:57 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6824 Title: TCP Extensions for Multipath Operation with Multiple Addresses Author: A. Ford, C. Raiciu, M. Handley, O. Bonaventure Status: Experimental Stream: IETF Date: January 2013 Mailbox: alanford@cisco.com, costin.raiciu@cs.pub.ro, m.handley@cs.ucl.ac.uk, olivier.bonaventure@uclouvain.be Pages: 64 Characters: 164866 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mptcp-multiaddressed-12.txt URL: http://www.rfc-editor.org/rfc/rfc6824.txt TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document defines an Experimental Protocol for the Internet community. This document is a product of the Multipath TCP Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From internet-drafts@ietf.org Sat Jan 19 10:43:46 2013 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 895A921F8589; Sat, 19 Jan 2013 10:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 UzNO8SYJDGYu; Sat, 19 Jan 2013 10:43:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5C621F854F; Sat, 19 Jan 2013 10:43:45 -0800 (PST) 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: 4.37 Message-ID: <20130119184345.14888.53913.idtracker@ietfa.amsl.com> Date: Sat, 19 Jan 2013 10:43:45 -0800 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-api-07.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 18:43:46 -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 IETF. Title : MPTCP Application Interface Considerations Author(s) : Michael Scharf Alan Ford Filename : draft-ietf-mptcp-api-07.txt Pages : 34 Date : 2013-01-19 Abstract: 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 which is a simple extension of TCP's interface for MPTCP-aware applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mptcp-api There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mptcp-api-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mptcp-api-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Thu Jan 31 06:16:31 2013 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 1703221F873B; Thu, 31 Jan 2013 06:16:31 -0800 (PST) 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 WB9RCmTjw+gk; Thu, 31 Jan 2013 06:16:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DDE21F8765; Thu, 31 Jan 2013 06:16:30 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130131141630.24708.10320.idtracker@ietfa.amsl.com> Date: Thu, 31 Jan 2013 06:16:30 -0800 Cc: mptcp mailing list , mptcp chair , RFC Editor Subject: [multipathtcp] Document Action: 'MPTCP Application Interface Considerations' to Informational RFC (draft-ietf-mptcp-api-07.txt) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 14:16:31 -0000 The IESG has approved the following document: - 'MPTCP Application Interface Considerations' (draft-ietf-mptcp-api-07.txt) as Informational RFC This document is the product of the Multipath TCP Working Group. The IESG contact persons are Wesley Eddy and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mptcp-api/ Technical Summary 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 which is a simple extension of TCP's interface for MPTCP-aware applications. Working Group Summary The document was not particularly controversial. There was very good consensus in the WG about the document. The document has been stable for quite a while, since it was decided to advance it in parallel with the MPTCP protocol. Document Quality The dcoument has been reviewed within the WG. Michael Tüxen (SCTP author) provided an expert review. There was also a WG last call, which resulted in some clarifications. An implementation of the protocol is publicly available, and other implementations are in progress. The API for MPTCP-aware applications has not been implemented to our knowledge. Personnel The document shepherd is Philip Eardley. The Responsible Area Director is Wes Eddy.