From marcelo@it.uc3m.es Tue Oct 1 07:56:04 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 92EB321F8AF4 for ; Tue, 1 Oct 2013 07:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eghl4K-yGc8H for ; Tue, 1 Oct 2013 07:55:59 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5661911E8179 for ; Tue, 1 Oct 2013 07:55:41 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 90C8611C0BF9 for ; Tue, 1 Oct 2013 16:55:40 +0200 (CEST) X-uc3m-safe: yes Received: from dummyhost0.it.uc3m.es (unknown [163.117.139.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 79A8D11C0B0E for ; Tue, 1 Oct 2013 16:55:40 +0200 (CEST) Message-ID: <524AE26B.4010303@it.uc3m.es> Date: Tue, 01 Oct 2013 16:55:39 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Multipath TCP Mailing List References: <20131001145402.21382.44791.idtracker@ietfa.amsl.com> In-Reply-To: <20131001145402.21382.44791.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131001145402.21382.44791.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp03.uc3m.es); Tue, 01 Oct 2013 16:55:40 +0200 (CEST) X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20188.004 X-TM-AS-Result: No--16.775-7.0-31-1 X-imss-scan-details: No--16.775-7.0-31-1 Subject: [multipathtcp] Fwd: New Version Notification for draft-bagnulo-mptcp-attacks-01.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 14:56:04 -0000 Hi, We have updated the draft to include one additional attack and soem reccomendations of next steps. We hope this serves as input for the interim meeting. Regards, marcelo -------- Mensaje original -------- Asunto: New Version Notification for draft-bagnulo-mptcp-attacks-01.txt Fecha: Tue, 01 Oct 2013 07:54:02 -0700 De: internet-drafts@ietf.org Para: Christoph Paasch , Fernando Gont , Olivier Bonaventure , Marcelo Bagnulo , Costin Raiciu , Olivier Bonaventure A new version of I-D, draft-bagnulo-mptcp-attacks-01.txt has been successfully submitted by Marcelo Bagnulo and posted to the IETF repository. Filename: draft-bagnulo-mptcp-attacks Revision: 01 Title: Analysis of MPTCP residual threats and possible fixes Creation date: 2013-10-01 Group: Individual Submission Number of pages: 25 URL: http://www.ietf.org/internet-drafts/draft-bagnulo-mptcp-attacks-01.txt Status: http://datatracker.ietf.org/doc/draft-bagnulo-mptcp-attacks Htmlized: http://tools.ietf.org/html/draft-bagnulo-mptcp-attacks-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-bagnulo-mptcp-attacks-01 Abstract: This documents performs an analysis of the residual threats for MPTCP and explores possible solutions to them. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From philip.eardley@bt.com Wed Oct 2 02:56:41 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 1E00921E80F1 for ; Wed, 2 Oct 2013 02:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.998 X-Spam-Level: X-Spam-Status: No, score=-102.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bICF0uAUSWmB for ; Wed, 2 Oct 2013 02:56:30 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id BA99421E82DD for ; Wed, 2 Oct 2013 02:54:47 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 2 Oct 2013 10:54:45 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.51]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Wed, 2 Oct 2013 10:54:45 +0100 From: To: Date: Wed, 2 Oct 2013 10:54:45 +0100 Thread-Topic: REMINDER: Thursday 3rd October: MPTCP interim (audio) meeting on security Thread-Index: Ac6/VH8d98/tuQV0RF2xbsmBKazLvQ== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9DD3A06EMV67UKRDdoma_" MIME-Version: 1.0 Cc: turners@ieca.com, stephen.farrell@cs.tcd.ie Subject: [multipathtcp] REMINDER: Thursday 3rd October: MPTCP interim (audio) meeting on security 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 Oct 2013 09:56:42 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9DD3A06EMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a reminder that tomorrow (Thursday) we have our interim call, to progr= ess improving security of MPTCP, in order to make progress on advancing RFC= 6824 on the standards track. Audio details etc at http://trac.tools.ietf.org/wg/mptcp/trac/wiki/Interim_= Oct_2013 3pm GMT (local times http://www.timeanddate.com/worldclock/fixedtime.html?m= sg=3DMPTCP+interim+Oct+2013&iso=3D20131003T15 ) Ps a volunteer to take notes would be excellent Thanks! From: Eardley,PL,Philip,TUB8 R Sent: 27 September 2013 11:57 To: multipathtcp@ietf.org Subject: RE: [multipathtcp] Thursday 3rd October: MPTCP interim (audio) mee= ting on security Chatting with a couple of people and thinking about the way forward. Marcelo has suggested a 2-pronged approach:- Prong 1: how to improve RFC6824 to solve the ADD_ADDR attack. The aim is to= get security equivalent to RFC5061 (SCTP with dynamic addresses). We can a= lso improve RFC6824 to make some of the fallback cases clearer (I remember = that came out of the implementation survey). We could hope to do this quite= quickly as a relatively small improvement to 6824, since there was some di= scussion on the list a while back how to solve this. Prong 2: RFC6824 sends the key in the clear on the MP_CAPABLE exchange - Wh= at could we do better? We've had some possibilities mentioned in the past,= but I don't think there's any consensus yet. Personally I think this seems a good way forward. We could do Prong 1 quick= ly if it looks like Prong 2 will take some time Comments on this approach welcome. Also if anyone would like a timeslot in the interim meeting, please let us = know Reading http://tools.ietf.org/html/draft-bagnulo-mptcp-attacks-00 thanks From: multipathtcp-bounces@ietf.org [= mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 09 September 2013 17:32 To: multipathtcp@ietf.org Subject: [multipathtcp] Thursday 3rd October: MPTCP interim (audio) meeting= on security Let's fix the date of the interim meeting for Thursday 3rd October at 3pm G= MT (note, the clocks change at different times in different regions of the = world, this time is in GMT/UTC) Will send audio details later Thanks! phil From: Eardley,PL,Philip,TUB8 R Sent: 06 September 2013 10:59 To: multipathtcp@ietf.org Subject: MPTCP interim (audio) meeting on security - please update your doo= dle I extended the doodle to the first week of October. Please could you update your entry or fill in Sorry for the trouble Thanks phil From: multipathtcp-bounces@ietf.org [= mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 04 September 2013 08:31 To: multipathtcp@ietf.org Subject: Re: [multipathtcp] MPTCP interim (audio) meeting on security, late= September Just to let you know. The Security Ads are kindly finding us a security adv= isor, but no luck yet. So we may have to delay this slightly. Also, it would be good if there was some discussion on the mailing list bef= ore the call. phil From: Eardley,PL,Philip,TUB8 R Sent: 21 August 2013 08:36 To: Eardley,PL,Philip,TUB8 R; multipathtcp@ietf.org Subject: RE: [multipathtcp] MPTCP interim (audio) meeting on security, late= September Just a reminder, as I know a lot of people have been on holiday, please fil= l in the doodle Thanks phil From: multipathtcp-bounces@ietf.org [= mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 06 August 2013 13:49 To: multipathtcp@ietf.org Subject: [multipathtcp] MPTCP interim (audio) meeting on security, late Sep= tember We think it would a good idea to have an interim (audio) meeting, in order = to make progress on advancing RFC 6824 on the standards track. We will discuss the security of the MPTCP protocol. The aim is to reach con= sensus on what security improvements are needed - and what are not needed -= in order to progress MPTCP on the Standards track. We hope to cover both t= he threat(s) that we will handle and, at a high-level, the solutions that w= ill be defined. Please fill in the doodle at http://doodle.com/xdf8eaiavvna9bcy#table For previous MPTCP WG interims, ~3pm GMT has been OK. Please shout if the t= ime is no good for you. In the meantime, please keep discussing MPTCP's security on the list! Thanks, Best wishes Phil & Yoshifumi --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9DD3A06EMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a reminder that tomo= rrow (Thursday) we have our interim call, to progress improving security of= MPTCP, in order to make progress on advancing RFC 6824 on the standards tr= ack.

 

Audio details etc at http://trac.tools= .ietf.org/wg/mptcp/trac/wiki/Interim_Oct_2013 =

3pm GMT (local times http://www.timeanddate.com/worldclock/f= ixedtime.html?msg=3DMPTCP+interim+Oct+2013&iso=3D20131003T15= )

 

Ps a volunteer to take notes would be excellent

 

Thanks!

 

<= p class=3DMsoNormal>From: Eardley,PL,Philip,TUB8 R
Sent: 27 S= eptember 2013 11:57
To: multipathtcp@ietf.org
Subject: = RE: [multipathtcp] Thursday 3rd October: MPTCP interim (audio) meeting on s= ecurity

 

Chatting with a couple of people and thinkin= g about the way forward.

&= nbsp;

Marcelo has suggested a 2-pron= ged approach:-

 

Prong 1: how to improve RFC6824 to solve= the ADD_ADDR attack. The aim is to get security equivalent to RFC5061 (SCT= P with dynamic addresses). We can also improve RFC6824 to make some of the = fallback cases clearer (I remember that came out of the implementation surv= ey). We could hope to do this quite quickly as a relatively small improveme= nt to 6824, since there was some discussion on the list a while back how to= solve this.

 =

Prong 2: RFC6824 sends the key in the cle= ar on the MP_CAPABLE exchange - What could we do better?  We’ve = had some possibilities mentioned in the past, but I don’t think there= ’s any consensus yet.

 

Personally I think this se= ems a good way forward. We could do Prong 1 quickly if it looks like Prong = 2 will take some time

&nb= sp;

Comments on this approach welcom= e.

Also if anyone would like a = timeslot in the interim meeting, please let us know

         =             &nb= sp;            =             &nb= sp;            =             &nb= sp;   

Reading<= o:p>

http://tools.ietf.org/html/draft-bag= nulo-mptcp-attacks-00

=  

thanks

<= p class=3DMsoNormal> 

 

From: multipathtcp-bounces@iet= f.org [mailto:multipat= htcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 09 September 2013 17= :32
To: multipathtcp@iet= f.org
Subject: [multipathtcp] Thursday 3rd October: MPTCP int= erim (audio) meeting on security

 

Let’s fix th= e date of the interim meeting for Thursday 3rd October at 3pm GM= T (note, the clocks change at different times in different regions of the w= orld, this time is in GMT/UTC)

=  

Will send audio details = later

 <= /p>

Thanks!

phil

 

From: Eardley,PL,Philip,= TUB8 R
Sent: 06 September 2013 10:59
To: multipathtcp@ietf.org
Subject: MP= TCP interim (audio) meeting on security - please update your doodle

 

I extended the doodle to the first week of October.

Please could you update your entry or = fill in

 

Sorry for the trouble

 

Thank= s

phil

 

From: mu= ltipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 04 September 2013 08:31
To: multipathtcp@ietf.org
Subject: Re: [multipathtcp] MPTCP= interim (audio) meeting on security, late September

<= /div>

 

<= span style=3D'font-size:12.0pt;font-family:"Arial","sans-serif";color:blue'= >Just to let you know. The Security Ads are kindly finding us a security ad= visor, but no luck yet. So we may have to delay this slightly.

Also, it would be good if there was some di= scussion on the mailing list before the call.

 

phil=

 

=

From:= Eardley,PL,Philip,TUB8 R
Sent: 21 August 2013 08:36
To: Eardley,PL,Philip,TUB8 R; multipathtcp@ietf.org
Subje= ct: RE: [multipathtcp] MPTCP interim (audio) meeting on security, late = September

 =

Just a reminder, as I know a lot of people= have been on holiday, please fill in the doodle

 

Thank= s

phil

 

From: mu= ltipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 06 August 2013 13:49
To: multipathtcp@ietf.org
Subject: [multipathtcp] MPTCP interi= m (audio) meeting on security, late September

 

We think it would= a good idea to have an interim (audio) meeting, in order to make progress = on advancing RFC 6824 on the standards track.

 

We will discuss the security of= the MPTCP protocol. The aim is to reach consensus on what security improve= ments are needed - and what are not needed - in order to progress MPTCP on = the Standards track. We hope to cover both the threat(s) that we will handl= e and, at a high-level, the solutions that will be defined.

 

Please fill in th= e doodle at http://doo= dle.com/xdf8eaiavvna9bcy#table

&= nbsp;

For previous MPTCP WG interims, ~3pm GMT = has been OK. Please shout if the time is no good for you.=

 

In the meantime, pl= ease keep discussing MPTCP’s security on the list!<= /p>

 

Thanks, <= /span>

Best wishes

Phil &am= p; Yoshifumi

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9DD3A06EMV67UKRDdoma_-- From turners@ieca.com Wed Oct 2 09:36:55 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 CF00C21F9E1A for ; Wed, 2 Oct 2013 09:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.865 X-Spam-Level: X-Spam-Status: No, score=-101.865 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_72=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnF0VnSYiquV for ; Wed, 2 Oct 2013 09:36:44 -0700 (PDT) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.88.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5670821F9B86 for ; Wed, 2 Oct 2013 09:34:58 -0700 (PDT) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id F2A8E3EC66689; Wed, 2 Oct 2013 11:34:57 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway12.websitewelcome.com (Postfix) with ESMTP id CCF133EC6660E for ; Wed, 2 Oct 2013 11:34:57 -0500 (CDT) Received: from [96.231.225.44] (port=65302 helo=thunderfish.local) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VRPO5-0006ay-9f; Wed, 02 Oct 2013 11:34:57 -0500 Message-ID: <524C4B30.708@ieca.com> Date: Wed, 02 Oct 2013 12:34:56 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: philip.eardley@bt.com References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.225.44]:65302 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 10 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Cc: multipathtcp@ietf.org, stephen.farrell@cs.tcd.ie Subject: Re: [multipathtcp] REMINDER: Thursday 3rd October: MPTCP interim (audio) meeting on security 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 Oct 2013 16:36:56 -0000 Unfortunately, this conflicts with the IESG informal telechat where we'll be deconflicting the upcoming IETF meeting's agenda. How long do you calls usually last, I might be able to call in if we get done early. spt On 10/2/13 5:54 AM, philip.eardley@bt.com wrote: > Just a reminder that tomorrow (Thursday) we have our interim call, to > progress improving security of MPTCP, in order to make progress on > advancing RFC 6824 on the standards track. > > Audio details etc at > http://trac.tools.ietf.org/wg/mptcp/trac/wiki/Interim_Oct_2013 > > 3pm GMT (local times > http://www.timeanddate.com/worldclock/fixedtime.html?msg=MPTCP+interim+Oct+2013&iso=20131003T15 > ) > > Ps a volunteer to take notes would be excellent > > Thanks! > > *From:*Eardley,PL,Philip,TUB8 R > *Sent:* 27 September 2013 11:57 > *To:* multipathtcp@ietf.org > *Subject:* RE: [multipathtcp] Thursday 3rd October: MPTCP interim > (audio) meeting on security > > Chatting with a couple of people and thinking about the way forward. > > Marcelo has suggested a 2-pronged approach:- > > Prong 1: how to improve RFC6824 to solve the ADD_ADDR attack. The aim is > to get security equivalent to RFC5061 (SCTP with dynamic addresses). We > can also improve RFC6824 to make some of the fallback cases clearer (I > remember that came out of the implementation survey). We could hope to > do this quite quickly as a relatively small improvement to 6824, since > there was some discussion on the list a while back how to solve this. > > Prong 2: RFC6824 sends the key in the clear on the MP_CAPABLE exchange - > What could we do better? We’ve had some possibilities mentioned in the > past, but I don’t think there’s any consensus yet. > > Personally I think this seems a good way forward. We could do Prong 1 > quickly if it looks like Prong 2 will take some time > > Comments on this approach welcome. > > Also if anyone would like a timeslot in the interim meeting, please let > us know > > Reading > > http://tools.ietf.org/html/draft-bagnulo-mptcp-attacks-00 > > thanks > > *From:*multipathtcp-bounces@ietf.org > > [mailto:multipathtcp-bounces@ietf.org] *On Behalf Of > *philip.eardley@bt.com > *Sent:* 09 September 2013 17:32 > *To:* multipathtcp@ietf.org > *Subject:* [multipathtcp] Thursday 3rd October: MPTCP interim (audio) > meeting on security > > Let’s fix the date of the interim meeting for Thursday 3^rd October at > 3pm GMT (note, the clocks change at different times in different regions > of the world, this time is in GMT/UTC) > > Will send audio details later > > Thanks! > > phil > > *From:*Eardley,PL,Philip,TUB8 R > *Sent:* 06 September 2013 10:59 > *To:* multipathtcp@ietf.org > *Subject:* MPTCP interim (audio) meeting on security - please update > your doodle > > I extended the doodle to the first week of October. > > Please could you update your entry or fill in > > Sorry for the trouble > > Thanks > > phil > > *From:*multipathtcp-bounces@ietf.org > > [mailto:multipathtcp-bounces@ietf.org] *On Behalf Of > *philip.eardley@bt.com > *Sent:* 04 September 2013 08:31 > *To:* multipathtcp@ietf.org > *Subject:* Re: [multipathtcp] MPTCP interim (audio) meeting on security, > late September > > Just to let you know. The Security Ads are kindly finding us a security > advisor, but no luck yet. So we may have to delay this slightly. > > Also, it would be good if there was some discussion on the mailing list > before the call. > > phil > > *From:*Eardley,PL,Philip,TUB8 R > *Sent:* 21 August 2013 08:36 > *To:* Eardley,PL,Philip,TUB8 R; multipathtcp@ietf.org > > *Subject:* RE: [multipathtcp] MPTCP interim (audio) meeting on security, > late September > > Just a reminder, as I know a lot of people have been on holiday, please > fill in the doodle > > Thanks > > phil > > *From:*multipathtcp-bounces@ietf.org > > [mailto:multipathtcp-bounces@ietf.org] *On Behalf Of > *philip.eardley@bt.com > *Sent:* 06 August 2013 13:49 > *To:* multipathtcp@ietf.org > *Subject:* [multipathtcp] MPTCP interim (audio) meeting on security, > late September > > We think it would a good idea to have an interim (audio) meeting, in > order to make progress on advancing RFC 6824 on the standards track. > > We will discuss the security of the MPTCP protocol. The aim is to reach > consensus on what security improvements are needed - and what are not > needed - in order to progress MPTCP on the Standards track. We hope to > cover both the threat(s) that we will handle and, at a high-level, the > solutions that will be defined. > > Please fill in the doodle at http://doodle.com/xdf8eaiavvna9bcy#table > > For previous MPTCP WG interims, ~3pm GMT has been OK. Please shout if > the time is no good for you. > > In the meantime, please keep discussing MPTCP’s security on the list! > > Thanks, > > Best wishes > > Phil & Yoshifumi > From stephen.farrell@cs.tcd.ie Wed Oct 2 10:00:10 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 0836821F9E33 for ; Wed, 2 Oct 2013 10:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5o6jfhNLTuh for ; Wed, 2 Oct 2013 09:59:58 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 04C5B21F97C7 for ; Wed, 2 Oct 2013 09:56:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 01126BEBB; Wed, 2 Oct 2013 17:56:50 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMcG-D-H2dli; Wed, 2 Oct 2013 17:56:47 +0100 (IST) Received: from [192.168.1.164] (r190-135-53-142.dialup.adsl.anteldata.net.uy [190.135.53.142]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 21EC7BEC4; Wed, 2 Oct 2013 17:56:45 +0100 (IST) Message-ID: <524C504B.6060804@cs.tcd.ie> Date: Wed, 02 Oct 2013 17:56:43 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Sean Turner , philip.eardley@bt.com References: <524C4B30.708@ieca.com> In-Reply-To: <524C4B30.708@ieca.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] REMINDER: Thursday 3rd October: MPTCP interim (audio) meeting on security 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 Oct 2013 17:00:10 -0000 On 10/02/2013 05:34 PM, Sean Turner wrote: > Unfortunately, this conflicts with the IESG informal telechat where > we'll be deconflicting the upcoming IETF meeting's agenda. How long do > you calls usually last, I might be able to call in if we get done early. And I'll be less likely to make it sorry. I'd encourage folks to think about moving the bar up to a tcpcrypt equivalent level of security for mptcp though - that seems well worth more than a look. S > > spt > > On 10/2/13 5:54 AM, philip.eardley@bt.com wrote: >> Just a reminder that tomorrow (Thursday) we have our interim call, to >> progress improving security of MPTCP, in order to make progress on >> advancing RFC 6824 on the standards track. >> >> Audio details etc at >> http://trac.tools.ietf.org/wg/mptcp/trac/wiki/Interim_Oct_2013 >> >> 3pm GMT (local times >> http://www.timeanddate.com/worldclock/fixedtime.html?msg=MPTCP+interim+Oct+2013&iso=20131003T15 >> >> ) >> >> Ps a volunteer to take notes would be excellent >> >> Thanks! >> >> *From:*Eardley,PL,Philip,TUB8 R >> *Sent:* 27 September 2013 11:57 >> *To:* multipathtcp@ietf.org >> *Subject:* RE: [multipathtcp] Thursday 3rd October: MPTCP interim >> (audio) meeting on security >> >> Chatting with a couple of people and thinking about the way forward. >> >> Marcelo has suggested a 2-pronged approach:- >> >> Prong 1: how to improve RFC6824 to solve the ADD_ADDR attack. The aim is >> to get security equivalent to RFC5061 (SCTP with dynamic addresses). We >> can also improve RFC6824 to make some of the fallback cases clearer (I >> remember that came out of the implementation survey). We could hope to >> do this quite quickly as a relatively small improvement to 6824, since >> there was some discussion on the list a while back how to solve this. >> >> Prong 2: RFC6824 sends the key in the clear on the MP_CAPABLE exchange - >> What could we do better? We’ve had some possibilities mentioned in the >> past, but I don’t think there’s any consensus yet. >> >> Personally I think this seems a good way forward. We could do Prong 1 >> quickly if it looks like Prong 2 will take some time >> >> Comments on this approach welcome. >> >> Also if anyone would like a timeslot in the interim meeting, please let >> us know >> >> Reading >> >> http://tools.ietf.org/html/draft-bagnulo-mptcp-attacks-00 >> >> thanks >> >> *From:*multipathtcp-bounces@ietf.org >> >> [mailto:multipathtcp-bounces@ietf.org] *On Behalf Of >> *philip.eardley@bt.com >> *Sent:* 09 September 2013 17:32 >> *To:* multipathtcp@ietf.org >> *Subject:* [multipathtcp] Thursday 3rd October: MPTCP interim (audio) >> meeting on security >> >> Let’s fix the date of the interim meeting for Thursday 3^rd October at >> 3pm GMT (note, the clocks change at different times in different regions >> of the world, this time is in GMT/UTC) >> >> Will send audio details later >> >> Thanks! >> >> phil >> >> *From:*Eardley,PL,Philip,TUB8 R >> *Sent:* 06 September 2013 10:59 >> *To:* multipathtcp@ietf.org >> *Subject:* MPTCP interim (audio) meeting on security - please update >> your doodle >> >> I extended the doodle to the first week of October. >> >> Please could you update your entry or fill in >> >> Sorry for the trouble >> >> Thanks >> >> phil >> >> *From:*multipathtcp-bounces@ietf.org >> >> [mailto:multipathtcp-bounces@ietf.org] *On Behalf Of >> *philip.eardley@bt.com >> *Sent:* 04 September 2013 08:31 >> *To:* multipathtcp@ietf.org >> *Subject:* Re: [multipathtcp] MPTCP interim (audio) meeting on security, >> late September >> >> Just to let you know. The Security Ads are kindly finding us a security >> advisor, but no luck yet. So we may have to delay this slightly. >> >> Also, it would be good if there was some discussion on the mailing list >> before the call. >> >> phil >> >> *From:*Eardley,PL,Philip,TUB8 R >> *Sent:* 21 August 2013 08:36 >> *To:* Eardley,PL,Philip,TUB8 R; multipathtcp@ietf.org >> >> *Subject:* RE: [multipathtcp] MPTCP interim (audio) meeting on security, >> late September >> >> Just a reminder, as I know a lot of people have been on holiday, please >> fill in the doodle >> >> Thanks >> >> phil >> >> *From:*multipathtcp-bounces@ietf.org >> >> [mailto:multipathtcp-bounces@ietf.org] *On Behalf Of >> *philip.eardley@bt.com >> *Sent:* 06 August 2013 13:49 >> *To:* multipathtcp@ietf.org >> *Subject:* [multipathtcp] MPTCP interim (audio) meeting on security, >> late September >> >> We think it would a good idea to have an interim (audio) meeting, in >> order to make progress on advancing RFC 6824 on the standards track. >> >> We will discuss the security of the MPTCP protocol. The aim is to reach >> consensus on what security improvements are needed - and what are not >> needed - in order to progress MPTCP on the Standards track. We hope to >> cover both the threat(s) that we will handle and, at a high-level, the >> solutions that will be defined. >> >> Please fill in the doodle at http://doodle.com/xdf8eaiavvna9bcy#table >> >> For previous MPTCP WG interims, ~3pm GMT has been OK. Please shout if >> the time is no good for you. >> >> In the meantime, please keep discussing MPTCP’s security on the list! >> >> Thanks, >> >> Best wishes >> >> Phil & Yoshifumi >> From olivier.bonaventure@uclouvain.be Thu Oct 3 05:45:00 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 7CF6E21F96ED for ; Thu, 3 Oct 2013 05:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShyI1wodqV8O for ; Thu, 3 Oct 2013 05:44:46 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5482921F9A7E for ; Thu, 3 Oct 2013 05:42:30 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id B5F9B1C625F; Thu, 3 Oct 2013 14:42:19 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be B5F9B1C625F DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1380804139; bh=ZMzxfG7+5gxvEY4iIdN7vdzoH4CrfZJcK6zVmhSD1mo=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: Content-Type:Content-Transfer-Encoding; b=xeCT2NNQwp0xkVN4Ya9FtHWInkU3UW9kqihBPlGEX46tOUf42JvNBifr7xLWaULXg HPiSwvk4cel1u5g8bTzv8sj4LusphyYEYU91vxRVsafxRfH1LV++borx3WiThxf3ak b1hg0rmyiQGGBrHVJwfrnv9BoSFLt45OP6cXpHmA= Message-ID: <524D6766.5030307@uclouvain.be> Date: Thu, 03 Oct 2013 14:47:34 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: B5F9B1C625F.A4223 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: Olivier Pereira Subject: [multipathtcp] Possible issue with MPTCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 12:45:00 -0000 Hello, While discussing about the security of MPTCP, one of our colleagues, Olivier Pereira, found an attack scenario for MPTCP that could lead to a DoS attack. The scenario is the following. C is the client, S the server and A the attacker. C has created an MPTCP connection with S and the three handshake has been done. C wants to create a second subflow and sends a SYN+MP_JOIN[Rc] to S. This MP_JOIN contains a nonce chosen by C. C -->--- MP_JOIN[Rc] -- The attacker captures the MP_JOIN[Rc]. This MP_JOIN takes some time to reach S. The attacker creates a SYN that contains a copy of the MP_JOIN and sends it back to C. C --- MP_JOIN[Rc] <---- A The client replies to this MP_JOIN by sending SYN+ACK containing MP_JOIN[HMAC(Key=(Ks,Kc), Msg=(Rx||Rc)] C ---- MP_JOIN[HMAC(Key=(Ks,Kc), Msg=(Rx||Rc)] -- > --- A The attacker sends a spoofed SYN_ACK packet from S to C containing the previous MP_JOIN C ---- MP_JOIN[HMAC(Key=(Ks,Kc), Msg=(Rx||Rc)] -------< --- S (spoofed) This MP_JOIN contains a valid HMAC. C accepts the connection establishment and replies with its third ack to S. This ack contains MP_JOIN[HMAC(Key=Kc,Ks),Msg=(Rc||Rx)] C--- MP_JOIN[HMAC(Key=Kc,Ks),Msg=(Rc||Rx)] --> --- S A captures this packet and replays the packet towards C. C --- MP_JOIN[HMAC(Key=Kc,Ks),Msg=(Rc||Rx)] --<--- A This terminates the connection establishment for the subflow between C and A. C has now two established subflows, the original one and the one with A. If S sends its SYN+ACK at this point, the SYN+ACK will contain a different random number and it will likely be rejected by C. The attacker has hijacked the connection. It needs to be able to spoof and capture packets. A possible scenario could be a first subflow established over a secure 3G network. Then the smartphone moves to an unprotected WiFi network and tries to establish an additional subflow over this network... Of course, when regular TCP is used in a network where attackers can spoof and capture packets, there is no guarantee in terms of security. Olivier and Christoph From mark@handley.org.uk Thu Oct 3 06:07:17 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 3BABF21F9C4A for ; Thu, 3 Oct 2013 06:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHvQvVtiRxdf for ; Thu, 3 Oct 2013 06:07:05 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE8D21F9D30 for ; Thu, 3 Oct 2013 06:03:17 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id AD48920B1E; Thu, 3 Oct 2013 09:03:15 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Thu, 03 Oct 2013 09:03:15 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=l5MpnsLgCRWGmhCUImhSasoaevw=; b=VJd gTVTIG7J42pk4vfCDbd18/ADlTRvz5TZqGT7H8+PqCrbMbzbYzAwp+kz74XTQMP7 JUFWZAU/j5fg2Wca4AeFJvqDi6ozeTVKmDo2ZCoKfv9mvdlhDGIq9nBCs02dWnv3 uV9h8LEenq2/2Da/XCSS9hyNcY53POvpc/Zo3MRQ= Received: by web4.nyi.mail.srv.osa (Postfix, from userid 99) id 8467D10B37D; Thu, 3 Oct 2013 09:03:15 -0400 (EDT) Message-Id: <1380805395.5769.29538061.34BE75F5@webmail.messagingengine.com> X-Sasl-Enc: Wy2YPl1HbB+fJvUUOUOcdiQCuueT1umqqX291ksHKVy/ 1380805395 From: Mark Handley To: Olivier Bonaventure , multipathtcp MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-ce174988 In-Reply-To: <524D6766.5030307@uclouvain.be> References: <524D6766.5030307@uclouvain.be> Date: Thu, 03 Oct 2013 06:03:15 -0700 Cc: Olivier Pereira Subject: Re: [multipathtcp] Possible issue with MPTCP 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 Oct 2013 13:07:17 -0000 Is the solution to this as simple as "don't accept an MP_JOIN with the same nonce as an MP_JOIN you've got outstanding?" Mark On Thu, Oct 3, 2013, at 05:47 AM, Olivier Bonaventure wrote: > Hello, > > > While discussing about the security of MPTCP, one of our colleagues, > Olivier Pereira, found an attack scenario for MPTCP that could lead to a > DoS attack. > > The scenario is the following. > > C is the client, S the server and A the attacker. > > C has created an MPTCP connection with S and the three handshake has > been done. > > C wants to create a second subflow and sends a SYN+MP_JOIN[Rc] to S. > This MP_JOIN contains a nonce chosen by C. > > C -->--- MP_JOIN[Rc] -- > > The attacker captures the MP_JOIN[Rc]. This MP_JOIN takes some time to > reach S. > > The attacker creates a SYN that contains a copy of the MP_JOIN and sends > it back to C. > > C --- MP_JOIN[Rc] <---- A > > The client replies to this MP_JOIN by sending SYN+ACK containing > MP_JOIN[HMAC(Key=(Ks,Kc), Msg=(Rx||Rc)] > > C ---- MP_JOIN[HMAC(Key=(Ks,Kc), Msg=(Rx||Rc)] -- > --- A > > The attacker sends a spoofed SYN_ACK packet from S to C containing the > previous MP_JOIN > > C ---- MP_JOIN[HMAC(Key=(Ks,Kc), Msg=(Rx||Rc)] -------< --- S (spoofed) > > > This MP_JOIN contains a valid HMAC. C accepts the connection > establishment and replies with its third ack to S. This ack contains > MP_JOIN[HMAC(Key=Kc,Ks),Msg=(Rc||Rx)] > > C--- MP_JOIN[HMAC(Key=Kc,Ks),Msg=(Rc||Rx)] --> --- S > > A captures this packet and replays the packet towards C. > > C --- MP_JOIN[HMAC(Key=Kc,Ks),Msg=(Rc||Rx)] --<--- A > > This terminates the connection establishment for the subflow between C > and A. C has now two established subflows, the original one and the one > with A. If S sends its SYN+ACK at this point, the SYN+ACK will contain a > different random number and it will likely be rejected by C. > > The attacker has hijacked the connection. It needs to be able to spoof > and capture packets. A possible scenario could be a first subflow > established over a secure 3G network. Then the smartphone moves to an > unprotected WiFi network and tries to establish an additional subflow > over this network... > > Of course, when regular TCP is used in a network where attackers can > spoof and capture packets, there is no guarantee in terms of security. > > > Olivier and Christoph > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From olivier.bonaventure@uclouvain.be Thu Oct 3 07:46:03 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 6D43521E80A8 for ; Thu, 3 Oct 2013 07:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id af26yEKBQXzU for ; Thu, 3 Oct 2013 07:45:44 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id EFCCE21E80AC for ; Thu, 3 Oct 2013 07:37:50 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 937441C71AE; Thu, 3 Oct 2013 16:37:34 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 937441C71AE DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1380811054; bh=zlKQ+vVtpHcRDTFVyvLtw+q+9qyCixIKK6UJPSZN2b4=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=grWlgVRpDukFbX9RUYnv/2Wppy4tEFFWXCzf6Hxc7j6s4agPQQCnrnLjhkbbX9eau JxQm21+CbCp2z6mfMNQebVH4L9tMBoS9Qv7w5i3Ui66WOEtl6jKmXitni+uF0DVuxG 7dZwrN66yxmcyjh1EWCJ3aRr+oHtoP44sfCEL4Dk= Message-ID: <524D8268.7050809@uclouvain.be> Date: Thu, 03 Oct 2013 16:42:48 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mark Handley References: <524D6766.5030307@uclouvain.be> <1380805395.5769.29538061.34BE75F5@webmail.messagingengine.com> In-Reply-To: <1380805395.5769.29538061.34BE75F5@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 937441C71AE.A08BD X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp , Olivier Pereira Subject: Re: [multipathtcp] Possible issue with MPTCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 14:46:03 -0000 On 3/10/13 15:03, Mark Handley wrote: > Is the solution to this as simple as "don't accept an MP_JOIN with the > same nonce as an MP_JOIN you've got outstanding?" This would fix this particular problem. It arises because there is some symmetry in the HMACs that are exchanged. It might be worth thinking a bit to see whether there are other situations were similar problems could arise. Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From philip.eardley@bt.com Fri Oct 4 02:20:41 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 DB7DA21F96ED for ; Fri, 4 Oct 2013 02:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKyDrocUfu3P for ; Fri, 4 Oct 2013 02:20:30 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEA521F9991 for ; Fri, 4 Oct 2013 02:16:58 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 4 Oct 2013 10:16:51 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.51]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Fri, 4 Oct 2013 10:16:51 +0100 From: To: Date: Fri, 4 Oct 2013 10:16:51 +0100 Thread-Topic: MPTCP Audio Call - minutes. Thread-Index: Ac7A4dPp4NIIWpu+Tl6c2sVHy0qScA== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [multipathtcp] MPTCP Audio Call - minutes. 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, 04 Oct 2013 09:20:42 -0000 Many thanks to John (Ronan) for taking some nice minutes. He joined late, s= o I added some less nice minutes about the start of the call. Please send any corrections to me & Yoshifumi Thanks phil ----- Phil: introduced meeting. See slides on wiki. Marcelo: Solving ADD-ADDR should be enough for Stds track, as similar to TCP and exa= ctly same as SCTP with dynamic addresses In parallel more secure version Alan, Phil, Mark: support approach Mark: as long as doesn't cause backwards compatibility issues later Proposal to have MPTCP signal to other end increased security Philip: Apps should be able to disable the 'increased security' syn option = on request. Request from client to server to not do mptcp... we don't want server to se= nd an add_addr option back to us. Marcelo: Negotiation needs to be more than just an option. Mark: Timing question, if we don't negotiate, (I missed a bit) how do we kn= ow when to send the add_addr message? Is this in prong one? Its not clear Marcelo: Missed his point Costin: Muffeled audio, question to Alan Alan: We have 4-5 (to be schecked) spare bits for the purposes of negotiati= ng encryption algorithms. Costin: Do we want to use a bit for this, or wait until a point in time, or Alan: Use one bit, binary, one or off... 'do not set up subflows yet' Mark: if we need to change the default behaviour with an extension, we shou= ld get it in as early as possible, even if it takes a few more years to com= e up with a stronger solution. Philip: Is it fair to say that there is generall agreement how to prevent t= his add_addr attack Marcelo: I was convinced by Oliver's argument. Mark: It seems sufficient.... there is a compatability issue ?:What issue? Mark: if we use Hmac in mp_join, we change its semantics Yohifumi: Not understanding what should be done in prong 2.. question is un= clear Marcelo Prong 1: update current spec, include hmac in add_addr..possibly update the= spec to the attack discussed is dealt with in the way mark suggested.. und= erstand if we need more to add compatability with what we do in prong2 (as = yet unknown) Nice thing If we get more secure key in the future.. having used hmac in ad= d_addr as well as mp_join means we can improve security of both similtaneou= sly Yoshi: Yes, this answers question 1.. missed next question Philip (summary): Prong1: Solve the add_addr attack by securing with hmac, think a bit more a= bout compatability to add negotiation, to handle elegantly better security = when its added in (prong2) and maybe... Philip, propose to discuss prong2 Invites Marcelo to discuss it Marcelo: 1. Secure the signalling only 2. Secure both signalling and data After discussion last week with group and it isn't clear if Unclear whether it is worth benefits not worth the trouble, If both are encrypted, then only a DoS is really left as a possible attack.= Solution space is much smaller, looks close to ssl or ??crypt.=20 First decision will be to either secure the signalling or both signalling a= nd payload Mark: Secured based on SSL, then payleoad is secured from payload insertion= already. Marcelo, how relevant are the threats? Mark: question is really does it increase the attack vectors? Marclo agrees= . Marcelo: broad point about whether using ssl (tcpcrypt) on top of MPTCP Mark: are we talking about doing tcpcrypt in mptcp working group Marclo: if this is they way forward, the iesg.... costin: any encrypted payload solution running on top of mptcp would be gre= at... (not sure), may need to do some things like make sure payload is goin= g to same box over all paths. Mark: Not securing add_addr allows for lots of injection/mitm scenarios. Marcelo: getting tcpcrypt in shape and adopted will take 12 months or more Marl: oroginally they were kept separate so one wouldn't drag the other dow= n. we could look at re-integrating them Mark: Negotiate tcp-crypt, turn off add_addr function, default protection o= f add_addr, question still in the air if tcp-crypt will protect add_addr op= tion. Costin: missed it.. mentioned post to mailing list.. Ed: That was me.. concern that middleboxes strip mptcp options, if you can'= t inspect it, I suspect intelligent middlboxes will develop mptcp proxys so= that they would be benevolent to data centre design. =20 Listening to the overall conversation... we do have to solve the add_addr i= ssue. ..independent... my concern is that if we make it hard for carriers/= enterprises to inspect the traffic, they will simply strip the options... t= hat will be it. Costin: If middlebox can do the encryption, then it knows the key and will use add_= addr to make sure all the paths go to the same box. If they can deal with = TLS, they should be able to deal with MPTCP. Maybe we need to understand a= bit more what middleboxes actually do so that when we design the security = we can take this into account. Ed: receive tcp connection on 80.. as we inspect, we move to servers, and m= ptcp gateway can now establish multiple subflows in a proxy type fashion...= benefit to enterprise is increased perfmance and reliability of traffic in= data centre... without having to deal with various other tech. it would e= nable enterprises to very simply increase performance and reliability, exam= ple how the proxy could be of benefit. Re indiegogo Idea of middlebox acting as a proxy and go to another device i= n a data centre.. even if it ultimately goes from mptcp to tcp, terminated = as a service... these are useful potential middlebox solution.. strangely e= nough.. integrity of direct client comms.. useful to have a middlbox in thi= s scenario. Missed question from Yoshi. Ed. do we want to be able to manipulate the options or just terminate...=20 I woudl be interested in being able to do this in somethign other than an e= xplicit format... more like a transparent proxy. Costin: audio ...transparent proxys are the problem.. if you have a transpa= rent middlebox does a mitm.. .then it is expicit... preferable to being tra= nsparent. Ed: one problem with transparent, is you end up with middlebox attempt to m= ultipath a subflow (recursive), looking more at explicit type proxy functio= nality. havent really objected to what is being said.. in explict mode, not= hing proposed thus far would be problematic. Missed question from Costin possibly. Philip: Marcelo.. in terms of your original question (secure signalling or = both)... my interpretation is... we should look at securing both.. or does = securing just the signalling need more exploring. Marcelo: practical approach.. we should start working on some of these opti= ons and see what people propose... i haven't seen any proposal for securing= the signalling... any other option. Ed: I'm not sure I'm convonced by the arcument that mptpcp by its very natu= re is increaseing the risk to the payload such that we have to force protec= tion on the payload.. I see them as independent concerns... if someone want= s to support tcpcrypt or TLS they are free to do so.. I understand the ques= tion re crossing nat boundarys.. but I would argue that that is not a signi= figant increase in risk over traditional TCP today. Marcelo: I think we fully agree.. that is why we have prong1. Mptcp today w= ith the few things we have identified that need to be done is similiar to t= cp, so we should move forward to standards track.. second can we do better = than today? My argument was, even though the signalling can be secured.. du= e to having to retain compatability with nat... it isn't worth doing, henc= e we may as well look to secure both Ed: Agree in principle, concerned about the overhead this would impose.... = datacentre owner, the cost of protecting the payload would be too high vis-= a-vis the benefits they are trying to achieve by deploying mptcp. Mark: No one is advocation anythign more than prong1 Marcelo: Data centres should just use prong 1 with fixes... Mark: there is an intermediate stage in the case where you don't have NAT..= could apply in data centre scenario. In the internet, there is no middle g= round that will make any sense.. Marcelo.. if you believe IPv6 will not have nat.. then prong1 with fixes is= fine. Ed: Transparent proxys are not going to be workable solutions.. I think man= ufacturers will participate with explicit proxys. Mark: missed his point re tcpproxy...does mptcp wg think this is something = we need? Philip: IESG may ask are we the only guys asking for it or do others requir= e it in a different context? Mark: if i'm to progress it I need someone to demand it. Marcelo: A good next step would be to understand how they would interact wi= th one another (mptcp and tcpcrypt)... its not as simple as stuff the optio= ns together Mark: yes, but not enough space Philip: separate at present Mark: yes Costin: question re hmac Mark: bit of mac and option header, thats about it (not sure about last two= /three exchances) Costin: could play with longer Data sequence mapping and hmac in different = segments..should keep overhead lower and Mark: might get extra compression doing that as well Costin: need to make sure it works for small data sequence payloads Mark: thats the penalty to be paid for that kind of security Costin:... in the initial syn, what is carried? Mark: pk??? option, hikack fist two packets of payload for public key negot= iation. Costin: there we need to think a bit more... need to go to.... Mark: discussed options Costin: Another observation... is it worthwhile to do the tcpcrypt handshak= e after the connection starts? Mark: can't trust anything until after the negotiation starts Discussion between Costin and Mark. Costin agreed with Mark at the end. Mark: There is current stuff in the MPTCP DSN option which can be taken out= if we do tcpcrypt. Costin: Yes Mark: Different discussion Philip: I'll post question to security AD's ...MPTCP may be interested in e= xploring it. Mark: point is that we may do want to couple them a little.. questions for = the AD's Philip: Anyone want to bring up anything else? Philip: discussion re Vancouver IETF. From philip.eardley@bt.com Fri Oct 4 02:25: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 6B20521F8F3C for ; Fri, 4 Oct 2013 02:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.498 X-Spam-Level: X-Spam-Status: No, score=-103.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUOyQninzTJQ for ; Fri, 4 Oct 2013 02:25:24 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 4134021F960D for ; Fri, 4 Oct 2013 02:19:49 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 4 Oct 2013 10:19:48 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.51]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Fri, 4 Oct 2013 10:19:48 +0100 From: To: Date: Fri, 4 Oct 2013 10:19:47 +0100 Thread-Topic: Summary of MPTCP interim meeting Thread-Index: Ac7A3gT4PDtOwxsPTHO7T4B448tv9g== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9DD3F1EEMV67UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] Summary of MPTCP interim meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 09:25:44 -0000 --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9DD3F1EEMV67UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks to everyone for joining the call yesterday. A quick summary of where= I think we got to, particularly so that people not on the call can check t= hey agree with the emerging consensus:- The 2-prong approach is good For prong 1 (small fixes to RFC6824 to get security exactly same as SCTP wi= th dynamic addresses & very similar to TCP security. We believe should be s= ufficient to get on Standards track), * we fix the ADD-ADDR attack (with HMAC - same method as for JOIN); * we think about solving the attack that Olivier mentioned on the l= ist yesterday; * we think about how to ensure future compatibility with Prong 2 on the last point, we want to make sure that MPTCP hosts will be able (opti= onally) to negotiate better security. This shouldn't need any major changes= (there is space in the MP_CAPABLE option), but we should define now how to= signal upgraded security For prong 2, (more secure), * 2 choices are to secure signalling better (as RFC6824 has keys in= the clear on the MP_CAPABLE exchange) - or to secure data as well * tentative conclusion is to go for second choice (just securing si= gnalling doesn't help because need to be compatible with NATs - and NATs ch= ange the source address therefore attacker can do same thing) * then two possibilities are SSL and TCPcrypt. Tend to favour TCPcr= ypt as secures more of the traffic * (side note - in this case, may want ADD_ADDR not to be HMAC'd so = the middleboxes can manipulate subflows (this is OK as data is secured - fo= r RFC6824bis we still want ADD_ADDR to be secured)) * Pursuing TCPcrypt needs AD input - is it just wanted by mptcp or = by other WGs? This affects eg whether we specify an integrated mptcp+tcpcry= pt Thanks phil --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9DD3F1EEMV67UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks to everyone for jo= ining the call yesterday. A quick summary of where I think we got to, parti= cularly so that people not on the call can check they agree with the emergi= ng consensus:-

 

The 2-prong approach is good

=  

For prong 1 (small fixes to RFC6824= to get security exactly same as SCTP with dynamic addresses & very sim= ilar to TCP security. We believe should be sufficient to get on Standards t= rack),

·<= span style=3D'font:7.0pt "Times New Roman"'>     &= nbsp;   we fix the ADD-ADDR attack (with HM= AC – same method as for JOIN);

·&= nbsp;        we th= ink about solving the attack that Olivier mentioned on the list yesterday; =

·      &n= bsp;  we think about how to ensure future compat= ibility with Prong 2

on the last point, w= e want to make sure that MPTCP hosts will be able (optionally) to negotiate= better security. This shouldn’t need any major changes (there is spa= ce in the MP_CAPABLE option), but we should define now how to signal upgrad= ed security

 

For prong 2, (more secure),

·=          2 ch= oices are to secure signalling better (as RFC6824 has keys in the clear on = the MP_CAPABLE exchange) – or to secure data as well

·         tentative conclusion is to go for second choice (just secur= ing signalling doesn’t help because need to be compatible with NATs &= #8211; and NATs change the source address therefore attacker can do same th= ing)

·     &nbs= p;   then two possibilities are SSL and TCP= crypt. Tend to favour TCPcrypt as secures more of the traffic

·         (side note – in this case, may want ADD_ADDR not t= o be HMAC’d so the middleboxes can manipulate subflows (this is OK as= data is secured – for RFC6824bis we still want ADD_ADDR to be secure= d))

·     &nbs= p;   Pursuing TCPcrypt needs AD input ̵= 1; is it just wanted by mptcp or by other WGs? This affects eg whether we s= pecify an integrated mptcp+tcpcrypt

&= nbsp;

Thanks

p= hil

= --_000_A2E337CDB7BC4145B018B9BEE8EB3E0D3FF9DD3F1EEMV67UKRDdoma_-- From philip.eardley@bt.com Fri Oct 4 02:42:07 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 07D0021F99E9 for ; Fri, 4 Oct 2013 02:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXpk8nV4tTEz for ; Fri, 4 Oct 2013 02:41:56 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC8921F9991 for ; Fri, 4 Oct 2013 02:41:42 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 4 Oct 2013 10:41:41 +0100 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.1.51]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Fri, 4 Oct 2013 10:41:41 +0100 From: To: Date: Fri, 4 Oct 2013 10:41:39 +0100 Thread-Topic: MPTCP Audio Call - minutes. Thread-Index: Ac7A4dPp4NIIWpu+Tl6c2sVHy0qScAAA6STQ Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multipathtcp] MPTCP Audio Call - minutes. 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, 04 Oct 2013 09:42:07 -0000 Also, here are the list of attendees (any corrections?): Alan Ford, Ed Lopez, Marcelo Bagnulo, Mark Handley, Olivier Bonaventure, Yo= shifumi Nishida, John Leslie, John Ronan, Costin Raiciu, Christoph Paasch, = Gregory Detal, Benjamin Hesmans, Philip Eardley > -----Original Message----- > From: multipathtcp-bounces@ietf.org [mailto:multipathtcp- > bounces@ietf.org] On Behalf Of philip.eardley@bt.com > Sent: 04 October 2013 10:17 > To: multipathtcp@ietf.org > Subject: [multipathtcp] MPTCP Audio Call - minutes. >=20 > Many thanks to John (Ronan) for taking some nice minutes. He joined > late, so I added some less nice minutes about the start of the call. > Please send any corrections to me & Yoshifumi Thanks phil >=20 > ----- > Phil: introduced meeting. See slides on wiki. >=20 > Marcelo: > Solving ADD-ADDR should be enough for Stds track, as similar to TCP and > exactly same as SCTP with dynamic addresses In parallel more secure > version >=20 > Alan, Phil, Mark: support approach >=20 > Mark: as long as doesn't cause backwards compatibility issues later >=20 > Proposal to have MPTCP signal to other end increased security >=20 > Philip: Apps should be able to disable the 'increased security' syn > option on request. >=20 > Request from client to server to not do mptcp... we don't want server > to send an add_addr option back to us. >=20 > Marcelo: Negotiation needs to be more than just an option. >=20 > Mark: Timing question, if we don't negotiate, (I missed a bit) how do > we know when to send the add_addr message? > Is this in prong one? Its not clear >=20 > Marcelo: Missed his point >=20 > Costin: Muffeled audio, question to Alan >=20 > Alan: We have 4-5 (to be schecked) spare bits for the purposes of > negotiating encryption algorithms. >=20 > Costin: Do we want to use a bit for this, or wait until a point in > time, or >=20 > Alan: Use one bit, binary, one or off... 'do not set up subflows yet' >=20 > Mark: if we need to change the default behaviour with an extension, we > should get it in as early as possible, even if it takes a few more > years to come up with a stronger solution. >=20 > Philip: Is it fair to say that there is generall agreement how to > prevent this add_addr attack >=20 > Marcelo: I was convinced by Oliver's argument. >=20 > Mark: It seems sufficient.... there is a compatability issue >=20 > ?:What issue? >=20 > Mark: if we use Hmac in mp_join, we change its semantics >=20 > Yohifumi: Not understanding what should be done in prong 2.. question > is unclear >=20 > Marcelo > Prong 1: update current spec, include hmac in add_addr..possibly update > the spec to the attack discussed is dealt with in the way mark > suggested.. understand if we need more to add compatability with what > we do in prong2 (as yet unknown) >=20 > Nice thing If we get more secure key in the future.. having used hmac > in add_addr as well as mp_join means we can improve security of both > similtaneously >=20 > Yoshi: Yes, this answers question 1.. missed next question >=20 > Philip (summary): > Prong1: Solve the add_addr attack by securing with hmac, think a bit > more about compatability to add negotiation, to handle elegantly better > security when its added in (prong2) and maybe... >=20 > Philip, propose to discuss prong2 Invites Marcelo to discuss it >=20 > Marcelo: > 1. Secure the signalling only > 2. Secure both signalling and data > After discussion last week with group and it isn't clear if >=20 > Unclear whether it is worth benefits not worth the trouble, >=20 > If both are encrypted, then only a DoS is really left as a possible > attack. Solution space is much smaller, looks close to ssl or ??crypt. > First decision will be to either secure the signalling or both > signalling and payload >=20 > Mark: Secured based on SSL, then payleoad is secured from payload > insertion already. >=20 > Marcelo, how relevant are the threats? >=20 > Mark: question is really does it increase the attack vectors? Marclo > agrees. >=20 > Marcelo: broad point about whether using ssl (tcpcrypt) on top of MPTCP >=20 > Mark: are we talking about doing tcpcrypt in mptcp working group > Marclo: if this is they way forward, the iesg.... >=20 > costin: any encrypted payload solution running on top of mptcp would be > great... (not sure), may need to do some things like make sure payload > is going to same box over all paths. >=20 > Mark: Not securing add_addr allows for lots of injection/mitm > scenarios. >=20 > Marcelo: getting tcpcrypt in shape and adopted will take 12 months or > more >=20 > Marl: oroginally they were kept separate so one wouldn't drag the other > down. we could look at re-integrating them >=20 > Mark: Negotiate tcp-crypt, turn off add_addr function, default > protection of add_addr, question still in the air if tcp-crypt will > protect add_addr option. >=20 > Costin: missed it.. mentioned post to mailing list.. >=20 > Ed: That was me.. concern that middleboxes strip mptcp options, if you > can't inspect it, I suspect intelligent middlboxes will develop mptcp > proxys so that they would be benevolent to data centre design. > Listening to the overall conversation... we do have to solve the > add_addr issue. ..independent... my concern is that if we make it hard > for carriers/enterprises to inspect the traffic, they will simply strip > the options... that will be it. >=20 > Costin: > If middlebox can do the encryption, then it knows the key and will use > add_addr to make sure all the paths go to the same box. If they can > deal with TLS, they should be able to deal with MPTCP. Maybe we need > to understand a bit more what middleboxes actually do so that when we > design the security we can take this into account. >=20 > Ed: receive tcp connection on 80.. as we inspect, we move to servers, > and mptcp gateway can now establish multiple subflows in a proxy type > fashion... benefit to enterprise is increased perfmance and reliability > of traffic in data centre... without having to deal with various other > tech. it would enable enterprises to very simply increase performance > and reliability, example how the proxy could be of benefit. >=20 > Re indiegogo Idea of middlebox acting as a proxy and go to another > device in a data centre.. even if it ultimately goes from mptcp to tcp, > terminated as a service... these are useful potential middlebox > solution.. strangely enough.. integrity of direct client comms.. useful > to have a middlbox in this scenario. >=20 > Missed question from Yoshi. >=20 > Ed. do we want to be able to manipulate the options or just > terminate... > I woudl be interested in being able to do this in somethign other than > an explicit format... more like a transparent proxy. >=20 > Costin: audio ...transparent proxys are the problem.. if you have a > transparent middlebox does a mitm.. .then it is expicit... preferable > to being transparent. >=20 > Ed: one problem with transparent, is you end up with middlebox attempt > to multipath a subflow (recursive), looking more at explicit type proxy > functionality. havent really objected to what is being said.. in > explict mode, nothing proposed thus far would be problematic. >=20 > Missed question from Costin possibly. >=20 > Philip: Marcelo.. in terms of your original question (secure signalling > or both)... my interpretation is... we should look at securing both.. > or does securing just the signalling need more exploring. >=20 > Marcelo: practical approach.. we should start working on some of these > options and see what people propose... i haven't seen any proposal for > securing the signalling... any other option. >=20 > Ed: I'm not sure I'm convonced by the arcument that mptpcp by its very > nature is increaseing the risk to the payload such that we have to > force protection on the payload.. I see them as independent concerns... > if someone wants to support tcpcrypt or TLS they are free to do so.. I > understand the question re crossing nat boundarys.. but I would argue > that that is not a signifigant increase in risk over traditional TCP > today. >=20 > Marcelo: I think we fully agree.. that is why we have prong1. Mptcp > today with the few things we have identified that need to be done is > similiar to tcp, so we should move forward to standards track.. second > can we do better than today? My argument was, even though the > signalling can be secured.. due to having to retain compatability with > nat... it isn't worth doing, hence we may as well look to secure both >=20 > Ed: Agree in principle, concerned about the overhead this would > impose.... datacentre owner, the cost of protecting the payload would > be too high vis-a-vis the benefits they are trying to achieve by > deploying mptcp. >=20 > Mark: No one is advocation anythign more than prong1 >=20 > Marcelo: Data centres should just use prong 1 with fixes... >=20 > Mark: there is an intermediate stage in the case where you don't have > NAT.. could apply in data centre scenario. In the internet, there is no > middle ground that will make any sense.. >=20 > Marcelo.. if you believe IPv6 will not have nat.. then prong1 with > fixes is fine. >=20 > Ed: Transparent proxys are not going to be workable solutions.. I think > manufacturers will participate with explicit proxys. >=20 > Mark: missed his point re tcpproxy...does mptcp wg think this is > something we need? > Philip: IESG may ask are we the only guys asking for it or do others > require it in a different context? >=20 > Mark: if i'm to progress it I need someone to demand it. >=20 > Marcelo: A good next step would be to understand how they would > interact with one another (mptcp and tcpcrypt)... its not as simple as > stuff the options together >=20 > Mark: yes, but not enough space >=20 > Philip: separate at present >=20 > Mark: yes >=20 > Costin: question re hmac >=20 > Mark: bit of mac and option header, thats about it (not sure about last > two/three exchances) >=20 > Costin: could play with longer Data sequence mapping and hmac in > different segments..should keep overhead lower and >=20 > Mark: might get extra compression doing that as well >=20 > Costin: need to make sure it works for small data sequence payloads >=20 > Mark: thats the penalty to be paid for that kind of security >=20 > Costin:... in the initial syn, what is carried? >=20 > Mark: pk??? option, hikack fist two packets of payload for public key > negotiation. >=20 > Costin: there we need to think a bit more... need to go to.... >=20 > Mark: discussed options >=20 > Costin: Another observation... is it worthwhile to do the tcpcrypt > handshake after the connection starts? >=20 > Mark: can't trust anything until after the negotiation starts >=20 > Discussion between Costin and Mark. Costin agreed with Mark at the end. >=20 > Mark: There is current stuff in the MPTCP DSN option which can be taken > out if we do tcpcrypt. >=20 > Costin: Yes >=20 > Mark: Different discussion >=20 > Philip: I'll post question to security AD's ...MPTCP may be interested > in exploring it. >=20 > Mark: point is that we may do want to couple them a little.. questions > for the AD's >=20 > Philip: Anyone want to bring up anything else? >=20 > > Philip: discussion re Vancouver IETF. >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From dreibh@iem.uni-due.de Fri Oct 4 07:13:28 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 17BF121F9E51 for ; Fri, 4 Oct 2013 07:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObB66yTq-RgZ for ; Fri, 4 Oct 2013 07:13:16 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id 41D7A21F9BFA for ; Fri, 4 Oct 2013 07:05:48 -0700 (PDT) Received: from lupo.localnet ([77.88.71.157]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id r94E5kqm019788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 4 Oct 2013 16:05:47 +0200 From: Thomas Dreibholz To: multipathtcp@ietf.org Date: Fri, 04 Oct 2013 16:05:46 +0200 Message-ID: <1519265.mvvsOKVC9a@lupo> Organization: University of Duisburg-Essen, Institute for Experimental Mathematics User-Agent: KMail/4.11.1 (Linux/3.8.0-31-generic; KDE/4.11.1; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2010579.Rup3cVrbVC"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Subject: [multipathtcp] Call for Papers of the PAMS 2014 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, 04 Oct 2013 14:13:28 -0000 --nextPart2010579.Rup3cVrbVC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" We apologize if you receive multiple copies of this CFP. CALL FOR PAPERS The 4th International Workshop on Protocols and Applications with Multi= -Homing=20 Support (PAMS 2014) In conjunction with the 28th IEEE International Conference on Advanced=20= Information Networking and Applications (AINA 2014) Victoria, BC/Canada, May 13-16, 2014 http://simula.no/pams2014 The intent of our workshop is to bring together people from research an= d industry, in order to provide a discussion forum for state-of-the-art t= opics related to multi-homing on Network, Transport, Session and Application = Layers. The PAMS workshop will include full-paper sessions as well as a poster = session (with short presentations) to introduce preliminary ideas as well as wo= rk in progress. Workshops proceedings will be published by the IEEE CS Conference Publi= shing Service and will be included in the Digital Library. The main topics to be addressed include (but are not limited to): * Network Resilience by Multi-Homing * Network Architectures for Multi-Homed Systems * Performance Evaluation of Multi-Homed Systems * Deployment of Multi-Homed Protocols in Existing Networks with Middleboxes * Design and Implementation of Multi-Homed Systems * Testbeds for Multi-Homed Systems * Load Sharing and Load Balancing for Multi-Homed Systems * Mobility for Multi-Homed Systems * Protocols with Multi-Homing Support * Congestion and Flow Control of Multi-Homed Systems * Quality of Service for Multi-Homed Systems * Multi-Homing for Interconnection Networks * Security of Multi-Homed Systems * Application Deployment and Support for Legacy Applications * Cross-Layer Optimisation for Multi-Homed Systems * Multi-Homing in the Context of the Future Internet GENERAL CHAIRS: * Thomas Dreibholz, Simula Research Laboratory, Norway * Hakim Adhari, University of Duisburg-Essen, Germany PROGRAM CHAIRS: * Martin Becke, University of Duisburg-Essen, Germany * Thomas Dreibholz, Simula Research Laboratory, Norway PUBLICITY CHAIRS: * Glenford Mapp, Middlesex University, United Kingdom * Xing Zhou, Hainan University, China PROGRAM COMMITTEE * Hakim Adhari, University of Duisburg-Essen, Germany * =C4=B0lknur Ayd=C4=B1n, Farmingdale State College, U.S.A. * =C5=81ukasz Budzisz, Technische Universit=C3=A4t Berlin, Germany * Nicola Altan, ista International, Germany * Paul Amer, University of Delaware, U.S.A. * Anna Brunstr=C3=B6m, Karlstad University, Sweden * Ahmed Elmokashfi, Simula Research Laboratory, Norway * Kristian Evensen, Simula Research Laboratory, Norway * Simone Ferlin, Simula Research Laboratory, Norway * Ernst Gunnar Gran, Simula Research Laboratory, Norway * Michio Honda, Keio University, Japan * Seok Joo Koh, Kyungpook National University, South Korea * Amund Kvalbein, Simula Research Laboratory, Norway * Glenford Mapp, Middlesex University, United Kingdom * Michael Menth, University of T=C3=BCbingen, Germany * Preethi Natarajan, Cisco, U.S.A. * Brad Penoff, Google, U.S.A. * Esbold Unurkhaan, Mongolian University of Science and Technology,= =20 Mongolia * Alan Wagner, University of British Columbia, Canada * Thomas Volkert, Ilmenau University of Technology, Germany * Michael Welzl, University of Oslo, Norway * Xing Zhou, Hainan University, China IMPORTANT DATES * Paper Submission Deadline: October 15, 2013 * Author Notification: December 20, 2013 * Author Registration: January 28, 2014 * Camera-Ready Paper Submission: February 11, 2014 CONTACT For further information, please contact: * Thomas Dreibholz (dreibh@simula.no) * Hakim Adhari (hakim.adhari@uni-due.de) WEBSITE http://simula.no/pams2014 --nextPart2010579.Rup3cVrbVC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlJOyzoACgkQ32BbsHYPLWU8dgCfe6AsYXhzmwd5ATU88eKFmMv9 +wwAn298InH3lJQfOqW/jPFIjamU2ljM =+JZX -----END PGP SIGNATURE----- --nextPart2010579.Rup3cVrbVC-- From nishida@sfc.wide.ad.jp Sat Oct 5 11:55:18 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 CE4FC21F8517 for ; Sat, 5 Oct 2013 11:55:18 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkP4LOL525hx for ; Sat, 5 Oct 2013 11:55:17 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 234D721F90A7 for ; Sat, 5 Oct 2013 11:55:14 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id CCC872780D7 for ; Sun, 6 Oct 2013 03:55:11 +0900 (JST) Received: by mail-lb0-f173.google.com with SMTP id o14so4330358lbi.18 for ; Sat, 05 Oct 2013 11:55:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=yA6xvaH+ZiiZpF63fqURvaKd4ZG6Qr2pwisr28zxnzY=; b=g2GeEzBSb5+D2EN0KiOv3AVE5Fo9nKgoW6ANa6puVYeynXoPbRPQBhmECQMwhjlt6G bMqMQVL6EXMrnPuccKP16o5wBPRtMtvYtp4WDasFvsr4trP1TCJr2NOgCNNAlfoJg+Hx ovMUMR03iiiEIohmlwe3VkHWx+pMUenE7HPa2OygsQr1mVzEjVaY3saFR9PuQaBZSDBo fF8iFZoq9WBF+oLCK90yPla+yuXCyY24Cns/YQkhOlBu4i147A323NS1iDdDna0c7wUN jwvR2bMXFr3Pc6sB1wo2pDYyhHKbvkOioE9wVveRddjU66dUdeA6WceZne1fuAXB0qcM 76+A== MIME-Version: 1.0 X-Received: by 10.152.6.169 with SMTP id c9mr2851114laa.28.1380999309257; Sat, 05 Oct 2013 11:55:09 -0700 (PDT) Received: by 10.114.230.231 with HTTP; Sat, 5 Oct 2013 11:55:09 -0700 (PDT) Date: Sat, 5 Oct 2013 11:55:09 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=089e01493c0643716004e802f5f0 Subject: [multipathtcp] mptcp supported router 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, 05 Oct 2013 18:55:18 -0000 --089e01493c0643716004e802f5f0 Content-Type: text/plain; charset=ISO-8859-1 Sound like an interesting news. http://gigaom.com/2013/10/01/multipath-networks-wants-to-mix-and-match-your-broadband-to-give-you-a-faster-pipe/ -- Yoshifumi --089e01493c0643716004e802f5f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sound like an interesting news.

<= a href=3D"http://gigaom.com/2013/10/01/multipath-networks-wants-to-mix-and-= match-your-broadband-to-give-you-a-faster-pipe/">http://gigaom.com/2013/10/= 01/multipath-networks-wants-to-mix-and-match-your-broadband-to-give-you-a-f= aster-pipe/

--
Yoshifumi
--089e01493c0643716004e802f5f0-- From tireddy@cisco.com Mon Oct 7 21:25:53 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 D770D21E8143 for ; Mon, 7 Oct 2013 21:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTe2HZxFtOz9 for ; Mon, 7 Oct 2013 21:25:48 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BA5FE21E813B for ; Mon, 7 Oct 2013 21:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3314; q=dns/txt; s=iport; t=1381206349; x=1382415949; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=yMeun2ESoZI1uYO4/zqNH2q+MTqWx1PoZl6/AifVa7Y=; b=ievCnTS5CYgsGxCJY0yZbLe4TIgkzd7KoO335UkQ0CN6KMV+QD+C8KYB T3MZ+dtDIBMgPkhcUaut5B60Y8oPxG3hgOIQbG2yof37yijWcbYZXc81J ldx/vTBEg6NZAbcm5yepnFuEHyBhbNs6hcEjua2cz/uKaTqAqIt6rWYE7 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFALOIU1KtJV2b/2dsb2JhbABZgwc4UoMovXoXgQgWbQeCJQEBAQQjEUMOBgEIEQQBAQMCBh0DAgQwFAEGAQEFBQQKCQgBh30MmgCPBpIpgSmNdxYogmQ1gQQDmTCQUYMkgio X-IronPort-AV: E=Sophos;i="4.90,1054,1371081600"; d="scan'208";a="269233507" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 08 Oct 2013 04:25:47 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r984PkL6014413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 8 Oct 2013 04:25:46 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 7 Oct 2013 23:25:46 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "multipathtcp@ietf.org" Thread-Topic: New Version Notification for draft-wing-mptcp-pcp-00.txt Thread-Index: AQHOwyU7Mjn+fqoYs0+81qJtg9SW25npfVoQ Date: Tue, 8 Oct 2013 04:25:45 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A190A66C5@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.64.68] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [multipathtcp] FW: New Version Notification for draft-wing-mptcp-pcp-00.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 04:25:54 -0000 UG9ydCBDb250cm9sIFByb3RvY29sIChQQ1AsIFJGQzY4ODcpIHByb3ZpZGVzIGEgbWVjaGFuaXNt IHRvIGRlc2NyaWJlIGEgZmxvdyB0byB0aGUgbmV0d29yay4gIFRoZSBwcmltYXJ5IGRyaXZlciBm b3IgUENQIGhhcyBiZWVuIGNyZWF0aW5nIHBvcnQgbWFwcGluZ3Mgb24gTkFUIGFuZCBmaXJld2Fs bCBkZXZpY2VzLiAgV2hlbiBkb2luZyB0aGlzLCBQQ1AgcHVzaGVzIGZsb3cgaW5mb3JtYXRpb24g ZnJvbSB0aGUgaG9zdCBpbnRvIHRoZSBuZXR3b3JrIChzcGVjaWZpY2FsbHkgdG8gdGhlIG5ldHdv cmsncyBOQVQgb3IgZmlyZXdhbGwgZGV2aWNlKSwgYW5kIHJlY2VpdmVzIGluZm9ybWF0aW9uIGJh Y2sgZnJvbSB0aGUgbmV0d29yayAoZnJvbSB0aGUgTkFUIG9yIGZpcmV3YWxsIGRldmljZSkuDQoN ClBDUCBjYW4gYWxzbyBiZSB1c2VkIHRvIHNpZ25hbCBmbG93IGNoYXJhY3RlcmlzdGljcyB0byB0 aGUgbmV0d29yaywgYW5kIHRoZSBuZXR3b3JrIHRvIHNpZ25hbCBpdHMgYWJpbGl0eSB0byBhY2Nv bW1vZGF0ZSB0aGF0IGZsb3cgYmFjayB0byB0aGUgaG9zdC4NClRoaXMgZHJhZnQgdXNlcyBQQ1Ag ZmxvdyBleHRlbnNpb25zIHRvIHNlbGVjdCB0aGUgYmVzdCBwYXRocyB3aGVuIG11bHRpcGxlIHBh dGhzIGFyZSBhdmFpbGFibGUgdG8gaW5mbHVlbmNlIE1QVENQIHN0YWNrIGZ1bmN0aW9ucy4gRm9y IGV4YW1wbGUgdGhlIE1QVENQIHN0YWNrIGNhbiBjaG9vc2UgdGhlIGludGVyZmFjZXMgZm9yIHRo ZSBwcmltYXJ5IGFuZCBzdWJzZXF1ZW50IHN1Yi1mbG93cyBhY2NvcmRpbmcgdG8gUENQIEZsb3cg ZXh0ZW5zaW9uIHJlc3BvbnNlcy4NCg0KWW91ciByZXZpZXdzL2NvbW1lbnRzL3N1Z2dlc3Rpb25z IGFyZSBhcHByZWNpYXRlZC4NCg0KLUF1dGhvcnMuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDA3LCAyMDEzIDExOjUwIEFNDQpU bzogQWxhbiBGb3JkOyBSYW0gTW9oYW4gUiAocm1vaGFucik7IFRpcnVtYWxlc3dhciBSZWRkeSAo dGlyZWRkeSk7IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKTsgUmFtIE1vaGFuIFIgKHJtb2hhbnIp OyBEYW4gV2luZyAoZHdpbmcpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXdpbmctbXB0Y3AtcGNwLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC13aW5nLW1wdGNwLXBjcC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgRGFuIFdpbmcgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmls ZW5hbWU6CSBkcmFmdC13aW5nLW1wdGNwLXBjcA0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgTXVs dGlwYXRoIFRDUCAoTVBUQ1ApIFBhdGggU2VsZWN0aW9uIHVzaW5nIFBDUA0KQ3JlYXRpb24gZGF0 ZToJIDIwMTMtMTAtMDcNCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9m IHBhZ2VzOiAxMA0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC13aW5nLW1wdGNwLXBjcC0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13aW5nLW1wdGNwLXBjcA0KSHRtbGl6 ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aW5nLW1wdGNwLXBj cC0wMA0KDQoNCkFic3RyYWN0Og0KICAgTXVsdGlQYXRoIFRDUCAoTVBUQ1ApIGFsbG93cyBhIGhv c3QgdG8gdXNlIG11bHRpcGxlIGludGVyZmFjZXMgdG8NCiAgIHRyYW5zZmVyIGRhdGEuICBXaXRo b3V0IGtub3dsZWRnZSBvZiB0aGUgY2hhcmFjdGVyaXNpdGNzIG9mIGVhY2gNCiAgIG5ldHdvcmsg cGF0aCwgdGhlIE1QVENQIHN0YWNrIGhhcyB0byBzZW5kIGRhdGEgdG8gbGVhcm4gdGhvc2UNCiAg IGNoYXJhY3RlcmlzdGljcy4gIFRoaXMgZG9jdW1lbnQgY29tbXVuaWNhdGVzIG5ldHdvcmsgY2hh cmFjdGVyaXN0aWNzDQogICB1c2luZyBQb3J0IENvbnRyb2wgUHJvdG9jb2woUENQKSB0byBhbGxv dyB0aGUgTVBUQ1Agc3RhY2sgaW5mbHVlbmNlDQogICBpdHMgZnVuY3Rpb25zLg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nishida@sfc.wide.ad.jp Mon Oct 7 21:40: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 6F76221E813B for ; Mon, 7 Oct 2013 21:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-NArbChr9KV for ; Mon, 7 Oct 2013 21:40:57 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id E30A421E81F9 for ; Mon, 7 Oct 2013 21:40:53 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 110502780A7 for ; Tue, 8 Oct 2013 13:40:49 +0900 (JST) Received: by mail-lb0-f171.google.com with SMTP id u14so6475599lbd.30 for ; Mon, 07 Oct 2013 21:40:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=Ar6TfC86L632BMM9S6tuA0pMErt0L2FmCMXq4mfYYrE=; b=O6gvm3ybulPlvN5ZIXcID2Rir5OD5K7w1aPYOPv7YZ1CdQEI7pg6SoAMse1of0fnc5 9+DGnRiZNQeWZyhqNwa0LYkdgqKzk5sbSpxQciUjleJFqHJ+mGqwrg9VseKMIEIWq55F xbME7FzOa/N8jiB9mLKTtRn9mR8Tss46l1Kk2BpoLvg6RIDU9iPLXQJdnaEoidfJB923 P1NzMlRrvL3a9VuxpexZJkhwkT3aOJ/2Ig8oDxlgiBBImF0z6FKp/I7je7Cq6htHKDdb rxHESFt9n+nYU25TrE2w0OSVbBLJhp0L1QsanJoxw+XivguCWZdCaaOqZNb3GGFt+wgH QtyQ== MIME-Version: 1.0 X-Received: by 10.112.198.39 with SMTP id iz7mr924478lbc.24.1381207247516; Mon, 07 Oct 2013 21:40:47 -0700 (PDT) Received: by 10.114.230.231 with HTTP; Mon, 7 Oct 2013 21:40:47 -0700 (PDT) Date: Mon, 7 Oct 2013 21:40:47 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] Agenda for Vancouver meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 04:40:57 -0000 Hello, The schedule has not been fixed yet, but we currently have the following two slots at the Vancouver meeting. Meeing 1: Date: Monday November 4, Afternoon Session III 17:40-19:40 Room: Georgia A Meeting 2: Date: Wednesday, November 6, Afternoon Session II 15:50-16:50 Room: Regency B If you're planning to present something, please provide us the following info. 1: presenter's name 2: title 3: length of the presentation Thanks, -- Yoshifumi & Phil From nishida@sfc.wide.ad.jp Mon Oct 7 23:40:20 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 983A321E8154 for ; Mon, 7 Oct 2013 23:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A72-0WgtHvnE for ; Mon, 7 Oct 2013 23:40:20 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id B63DE21E8157 for ; Mon, 7 Oct 2013 23:40:08 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2E2132780A7 for ; Tue, 8 Oct 2013 15:40:05 +0900 (JST) Received: by mail-lb0-f170.google.com with SMTP id w7so6552171lbi.29 for ; Mon, 07 Oct 2013 23:40:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=j7KH+JePDNZuFBpM5iUrXBGL8sAW9oeXXrQO+g9+pGM=; b=DjQlnwD5zklejFYqYzy5nZT1rpUMszL+3/mM5vfp4SrjniKoH5jCwylmm7qHap7c17 1JLS4VPunLOrFnn56mh+ScRRDkXMUXRgyJs1fgTwdmvCIAOoQ8JvEqWgiv//5a6vw4/o IqqbonBwWYtsOTkskP6wVXOZn1fHMqmBV4idFJmYxgVJQ9P0/7SHokCFTbQSBPQ86zeo UeT8wxOCbLyWqP6LawPsA3vUNIZybzPckxazDznaZ5M1m5Tw63Rnhm/TEi2OzPa8/qwY L3Z9ijhQz4R3xN3jt8n2y0RygwUVGWSLOjxhEMyeogjdFwo0jwReCgf/3cJXBolzLGAe CglA== MIME-Version: 1.0 X-Received: by 10.152.29.103 with SMTP id j7mr1201lah.7.1381214403624; Mon, 07 Oct 2013 23:40:03 -0700 (PDT) Received: by 10.114.230.231 with HTTP; Mon, 7 Oct 2013 23:40:03 -0700 (PDT) Date: Mon, 7 Oct 2013 23:40:03 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] hotnets paper related to mptcp security X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 06:40:20 -0000 Although it's not published yet, "Cross-Path Inference Attacks on Multipath TCP" seems to be an attractive title. I'm guessing we will need to take a look at this once it's published.. http://conferences.sigcomm.org/hotnets/2013/program.shtml -- Yoshifumi From olivier.bonaventure@uclouvain.be Tue Oct 8 00:03:09 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 D147121E8159 for ; Tue, 8 Oct 2013 00:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nq2fpkqTWUQw for ; Tue, 8 Oct 2013 00:03:05 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7F66D21E8151 for ; Tue, 8 Oct 2013 00:03:04 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 7B814B404D; Tue, 8 Oct 2013 09:02:46 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 7B814B404D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1381215766; bh=/IApyFdujHxjdd7ybpGI8f2jLmZn8z4oWG4lI08Gias=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=cnc6tDjYz7HMU/cZ4A/WJT4kzGAREPuUJ88Bxod9Nc22mRQpHlED0cg6rj8cVOckC qGYfatNhmZES6ahpJJP6bI9rPfl0TF2sJo/Q4cKezYcfS/jmfkolMKEtVaCupYaIFt 7m4bvViU9IRp/DNB4KeehWNpTv1SOz5IKrrd8LXE= Message-ID: <5253AE18.90100@uclouvain.be> Date: Tue, 08 Oct 2013 09:02:48 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yoshifumi Nishida References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 7B814B404D.A5814 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp Subject: Re: [multipathtcp] hotnets paper related to mptcp security X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 07:03:09 -0000 Yoshifumi, > Although it's not published yet, "Cross-Path Inference Attacks on > Multipath TCP" seems to be an attractive title. I'm guessing we will > need to take a look at this once it's published.. > > http://conferences.sigcomm.org/hotnets/2013/program.shtml There are other Multipath TCP papers that have been accepted and will be published in the coming months, e.g. Conext 2013 • On the Benefits of Applying Experimental Design to Improve Multipath TCP Christoph Paasch (UCLouvain), Ramin Khalili (T-Labs/TU-Berlin), Olivier Bonaventure (UCLouvain) IMC 2013 A Measurement-based Study of Multipath TCP performance over Wireless Networks (review) (long), Y.-C. Chen, Y.-S. Lim (UMass Amherst), R.J. Gibbens (University of Cambridge), E.M. Nahum (IBM Research), R. Khalili (Deutsche Telekom) and D. Towsley (UMass Amherst) The Hotmiddlebox workshop at Conext will also feature Multipath TCP related papers Stay tuned :-) Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From michawe@ifi.uio.no Tue Oct 8 05:00: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 78BF421E81E2 for ; Tue, 8 Oct 2013 05:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfXyat2YpZhd for ; Tue, 8 Oct 2013 05:00:31 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCC921E8198 for ; Tue, 8 Oct 2013 05:00:30 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VTVxl-0007gR-EQ for multipathtcp@ietf.org; Tue, 08 Oct 2013 14:00:29 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VTVxk-0000Bt-Vy for multipathtcp@ietf.org; Tue, 08 Oct 2013 14:00:29 +0200 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_0DF46435-81F3-4E9D-8B68-4DAC93F239F8" Date: Tue, 8 Oct 2013 14:00:28 +0200 Message-Id: <2F607756-9179-4F35-90B9-CC0F7BB3B760@ifi.uio.no> To: multipathtcp Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 10 sum msgs/h 6 total rcpts 8236 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: FC37C504E816F37681C1EE672C380FC367B05111 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 3220 max/h 16 blacklist 0 greylist 0 ratelimit 0 Subject: [multipathtcp] Call for participation: Transport Services X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 12:00:37 -0000 --Apple-Mail=_0DF46435-81F3-4E9D-8B68-4DAC93F239F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, Sorry if you receive multiple copies of this! I sent it to all the lists = with potentially interested folks... (this should be okay to do = according to RFC5434, which says "various mailing lists"). A community of interest is being formed to gauge whether there is = sufficient interest to host a BOF at the London IETF, on the topic of = "Transport Services". The intention is to create a WG that would define = the set of services that transport protocols offer to applications, such = that applications could at some point in the future request a service, = not a protocol. This could foster innovation (protocols could be tried = out, with a fall-back, without requiring the application programmer to = include such functionality); it could also give more freedom to whatever = resides below the API to automatically make the best out of what it = currently has available. If you're interested in this problem space, please visit the related = webpage that I have set up: https://sites.google.com/site/transportprotocolservices/ There you'll find an initial stab at a charter and all information about = the mailing list - please join us and participate in discussions! = Thanks! Cheers, Michael --Apple-Mail=_0DF46435-81F3-4E9D-8B68-4DAC93F239F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

A community of = interest is being formed to gauge whether there is sufficient interest = to host a BOF at the London IETF, on the topic of "Transport Services". = The intention is to create a WG that would define the set of services = that transport protocols offer to applications, such that applications = could at some point in the future request a service, not a protocol. = This could foster innovation (protocols could be tried out, with a = fall-back, without requiring the application programmer to include such = functionality); it could also give more freedom to whatever resides = below the API to automatically make the best out of what it currently = has available.

If you're interested in this = problem space, please visit the related webpage that I have set = up:
There = you'll find an initial stab at a charter and all information about = the mailing list - please join us and participate in discussions! = Thanks!

Cheers,
Michael

<= /div>= --Apple-Mail=_0DF46435-81F3-4E9D-8B68-4DAC93F239F8-- From dreibh@iem.uni-due.de Tue Oct 15 12:43:25 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 B7C7B11E8156 for ; Tue, 15 Oct 2013 12:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWqJZ4PihDna for ; Tue, 15 Oct 2013 12:43:20 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id E844D21F9FC8 for ; Tue, 15 Oct 2013 12:43:14 -0700 (PDT) Received: from lupo.localnet (cm-84.215.18.138.getinternet.no [84.215.18.138]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id r9FJhCIJ013670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 15 Oct 2013 21:43:13 +0200 From: Thomas Dreibholz To: multipathtcp@ietf.org Date: Tue, 15 Oct 2013 21:35:46 +0200 Message-ID: <1778430.LoUkx6JSon@lupo> Organization: University of Duisburg-Essen, Institute for Experimental Mathematics User-Agent: KMail/4.11.2 (Linux/3.8.0-31-generic; KDE/4.11.2; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart11059459.o562DhCk2T"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Subject: [multipathtcp] [Extended Deadline] Call for Papers of the PAMS 2014 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 19:43:25 -0000 --nextPart11059459.o562DhCk2T Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" We apologize if you receive multiple copies of this CFP. CALL FOR PAPERS The 4th International Workshop on Protocols and Applications with Multi= -Homing=20 Support (PAMS 2014) In conjunction with the 28th IEEE International Conference on Advanced=20= Information Networking and Applications (AINA 2014) Victoria, BC/Canada, May 13-16, 2014 http://simula.no/pams2014 The intent of our workshop is to bring together people from research an= d industry, in order to provide a discussion forum for state-of-the-art t= opics related to multi-homing on Network, Transport, Session and Application = Layers. The PAMS workshop will include full-paper sessions as well as a poster = session (with short presentations) to introduce preliminary ideas as well as wo= rk in progress. Workshops proceedings will be published by the IEEE CS Conference Publi= shing Service and will be included in the Digital Library. The main topics to be addressed include (but are not limited to): * Network Resilience by Multi-Homing * Network Architectures for Multi-Homed Systems * Performance Evaluation of Multi-Homed Systems * Deployment of Multi-Homed Protocols in Existing Networks with Middleboxes * Design and Implementation of Multi-Homed Systems * Testbeds for Multi-Homed Systems * Load Sharing and Load Balancing for Multi-Homed Systems * Mobility for Multi-Homed Systems * Protocols with Multi-Homing Support * Congestion and Flow Control of Multi-Homed Systems * Quality of Service for Multi-Homed Systems * Multi-Homing for Interconnection Networks * Security of Multi-Homed Systems * Application Deployment and Support for Legacy Applications * Cross-Layer Optimisation for Multi-Homed Systems * Multi-Homing in the Context of the Future Internet GENERAL CHAIRS: * Thomas Dreibholz, Simula Research Laboratory, Norway * Hakim Adhari, University of Duisburg-Essen, Germany PROGRAM CHAIRS: * Martin Becke, University of Duisburg-Essen, Germany * Thomas Dreibholz, Simula Research Laboratory, Norway PUBLICITY CHAIRS: * Glenford Mapp, Middlesex University, United Kingdom * Xing Zhou, Hainan University, China PROGRAM COMMITTEE * Hakim Adhari, University of Duisburg-Essen, Germany * =C4=B0lknur Ayd=C4=B1n, Farmingdale State College, U.S.A. * =C5=81ukasz Budzisz, Technische Universit=C3=A4t Berlin, Germany * Nicola Altan, ista International, Germany * Paul Amer, University of Delaware, U.S.A. * Anna Brunstr=C3=B6m, Karlstad University, Sweden * Ahmed Elmokashfi, Simula Research Laboratory, Norway * Kristian Evensen, Simula Research Laboratory, Norway * Simone Ferlin, Simula Research Laboratory, Norway * Ernst Gunnar Gran, Simula Research Laboratory, Norway * Michio Honda, Keio University, Japan * Seok Joo Koh, Kyungpook National University, South Korea * Amund Kvalbein, Simula Research Laboratory, Norway * Glenford Mapp, Middlesex University, United Kingdom * Michael Menth, University of T=C3=BCbingen, Germany * Preethi Natarajan, Cisco, U.S.A. * Brad Penoff, Google, U.S.A. * Esbold Unurkhaan, Mongolian University of Science and Technology,= =20 Mongolia * Alan Wagner, University of British Columbia, Canada * Thomas Volkert, Ilmenau University of Technology, Germany * Michael Welzl, University of Oslo, Norway * Xing Zhou, Hainan University, China IMPORTANT DATES * Paper Submission Deadline: November 1, 2013 (extended) * Author Notification: December 20, 2013 * Author Registration: January 28, 2014 * Camera-Ready Paper Submission: February 11, 2014 CONTACT For further information, please contact: * Thomas Dreibholz (dreibh@simula.no) * Hakim Adhari (hakim.adhari@uni-due.de) WEBSITE http://simula.no/pams2014 --nextPart11059459.o562DhCk2T Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlJdmRIACgkQ32BbsHYPLWXdyQCgmMX6R0FXUJNNL+11M3cz+c+5 r/QAoItA7Ll3Tyo1it79qL0ifEaG9l/P =H1QJ -----END PGP SIGNATURE----- --nextPart11059459.o562DhCk2T-- From internet-drafts@ietf.org Mon Oct 21 02:44:19 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 2621111E838F; Mon, 21 Oct 2013 02:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hplM9wbQH6Hy; Mon, 21 Oct 2013 02:44:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE9411E8117; Mon, 21 Oct 2013 02:41:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021094121.29534.54425.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 02:41:21 -0700 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-00.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 09:44:19 -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 : TCP Extensions for Multipath Operation with Multiple Add= resses Author(s) : Alan Ford Costin Raiciu University Politehnica of Bucharest Mark Handley Olivier Bonaventure Filename : draft-ietf-mptcp-rfc6824bis-00.txt Pages : 64 Date : 2013-10-20 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From raminster@gmail.com Mon Oct 21 02:49:01 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 B6BC411E825C for ; Mon, 21 Oct 2013 02:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.715 X-Spam-Level: X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUZe8w7NMXb4 for ; Mon, 21 Oct 2013 02:49:00 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AFB5B11E84FF for ; Mon, 21 Oct 2013 02:46:14 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id tp5so11383441ieb.17 for ; Mon, 21 Oct 2013 02:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=LG8MiHLwXINdPvjbyTgVngV7W26uKWRHCra7IEs6MxE=; b=sNfvaBtYaf/hgk/tv2Mo2u1DrT41WmA0UTpymXvg8RzB1G6WEZGK4PO2w7zAKgT2tr sVBsrxZGgUxT75A4bz3y59KQkbyiVEGPz1GkRQGapxmgrGa0aTUk3BP0vW6+UkvZe26q o7iwFClZWHHmHeg969cHCKyXDB9rN45ytSstcg8JHwoVal/ZSJeZE5+sqh79mP6by+Ku 1RVzYK7PI9xJcLS6jhsfCP4v4lJmQ7MsWkJxTYPwjhd/a71PLJ0Gy2JprUnMYis+sUkg bjkJWFPeGsewTDlnQ1l33/DRnghrLhrIFmBcMxGo74eos/WiV/pmFqb/D4VN9rkV0s3k 0SSQ== MIME-Version: 1.0 X-Received: by 10.43.132.66 with SMTP id ht2mr9679392icc.26.1382348772277; Mon, 21 Oct 2013 02:46:12 -0700 (PDT) Received: by 10.64.62.9 with HTTP; Mon, 21 Oct 2013 02:46:12 -0700 (PDT) Date: Mon, 21 Oct 2013 11:46:12 +0200 Message-ID: From: Ramin Khalili To: nishida@sfc.wide.ad.jp, nicolas.kuhn@isae.fr, multipathtcp@ietf.org Content-Type: multipart/mixed; boundary=20cf307f31fe870fb104e93d27c2 X-Mailman-Approved-At: Mon, 21 Oct 2013 03:26:27 -0700 Subject: Re: [multipathtcp] some comments on draft-khalili-mptcp-congestion-control-01 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 09:52:39 -0000 --20cf307f31fe870fb104e93d27c2 Content-Type: multipart/alternative; boundary=20cf307f31fe870fac04e93d27c0 --20cf307f31fe870fac04e93d27c0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Nicolas, Yoshifumi, Thanks for your comments and points. We have apply them in our draft and will submit the new version of our draft by this afternoon (I will send a submission notice when the new version is available). With regards to the question about ssthresh, as Nicolas said, the main goal is to to avoid the overuse of a congested path whereas other paths are available. With Christoph Paasch from UCLouvain, we have done a number of experiments to study the effect of setting the minimum ssthresh to 1. We observed that it improves the load balancing in the network but the gain is not very significant. Note that minimum ssthresh for single path TCP would be still 2 MSS; hence, our modification will not effect the single path TCP performance. Cheers, Ramin. -------- Original Message -------- Subject: Re: [multipathtcp] some comments on draft-khalili-mptcp-**congestion-control-01 Date: Thu, 26 Sep 2013 00:32:42 -0700 From: Yoshifumi Nishida To: Nicolas Kuhn CC: multipathtcp Hi Nicolas, Thanks for the response. On Mon, Sep 23, 2013 at 12:01 AM, Nicolas Kuhn > wrote: Hello, Le 23/09/2013 08:00, Yoshifumi Nishida a =E9crit : > Hello, > I've read draft-khalili-mptcp-**congestion-control-01 with great > interests and have the following comments. Please let me know if I > miss something. > > 1: It seems to me that how to determine collective_paths and > max_w_paths are a bit ambiguous. Since they are "paths", it seems > that they are expected to be more than 1. > However, I'm not very sure about the logic to choose them. For > example, if 3 paths have > 10MSS, 20MSS, 30MSS cwnd respectively, do we choose the 20MSS path > as one of max_w_paths? Or, how about 10MSS, 29MSS, 30MSS case? > > More details can be found in [5], Section 4.1: Equations (3) and (4) should be included in the draft. OK. Thanks for the info. 2: Do we really need to set the ssthresh to 1 MSS when multiple > paths are used? RFC6356 doesn't have this kind of logic. I'm > wondering why this is required. Also, in case of single path, the > draft requires to set the ssthresh to 2 MSS, but I'm not very sure > about the rationale behind this. > > This may be required to avoid the overuse of a congested path whereas other paths are available. If there are many paths, there is no use in spoiling media resources with ssthresh set to 2 MSS. I guess this parameter is set to 1 MSS to properly only analyze the traffic around. The authors may have more explanations than I do. I personally think setting small ssthresh is not very necessarily, especially for single path case. If this is an important point for the logic, I would like to see some rationale in the draft. I hope authors will address this in new version. Thanks, -- Yoshifumi --20cf307f31fe870fac04e93d27c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= = Dear Nicolas, Yoshifumi,

Thanks for your comments and points. We have apply them in our draft and will submit the new version of our draft by this afternoon (I will send a submission notice when the new version is available).

With regards to the question about ssthresh, as Nicolas said, the main goal is to to avoid the overuse of a congested path whereas other paths are available.=A0

With Christop= h Paasch from UCLouvain, we have done a number of experiments to study the = effect of setting the minimum ssthresh to 1.=A0= We observed that it improves the load balancing in the network but the gain is not very significant.=A0Note th= at minimum ssthresh for single path TCP would be still 2 MSS; hence, our modification will not effect the single path TCP performance.

Cheers,

Ramin. =A0 =A0


<= br>
-------- Original Message --------
Subject: =A0 =A0 =A0 =A0Re: [multipathtcp] some comments on
draft-khalili-mptcp-congestion-control-01
Date: =A0 Thu, 26 Sep 2013 00:32:42 -0700
From: =A0 Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
To: =A0 =A0 Nicolas Kuhn <nicolas.kuhn@isae.fr>
CC: =A0 =A0 multipathtcp <multipathtcp@ietf.org>



Hi Nicolas,

Thanks for the response.

On Mon, Sep 23, 2013 at 12:01 AM, Nicolas Kuhn <nicolas.kuhn@isae.fr
<mailto:nicola= s.kuhn@isae.fr>> wrote:

=A0 =A0 Hello,

=A0 =A0 Le 23/09/2013 08:00, Yoshifumi Nishida a =E9crit :
=A0 =A0 Hello,
=A0 =A0 I've read draft-khalili-mptcp-congestion-control-01 with= great
=A0 =A0 interests and have the following comments. Please let me know if I<= br> =A0 =A0 miss something.

=A0 =A0 1: It seems to me that how to determine collective_paths and
=A0 =A0 max_w_paths are a bit ambiguous. Since they are "paths", = it seems
=A0 =A0 that they are expected to be more than 1.
=A0 =A0 However, I'm not very sure about the logic to choose them. For<= br> =A0 =A0 example, if 3 paths have
=A0 =A0 10MSS, 20MSS, 30MSS cwnd respectively, do we choose the 20MSS path<= br> =A0 =A0 as one of max_w_paths? Or, how about 10MSS, 29MSS, 30MSS case?

=A0 =A0 More details can be found in [5], Section 4.1: Equations (3) and (4= )
=A0 =A0 should be included in the draft.


OK. Thanks for the info.

=A0 =A0 2: Do we really need to set the ssthresh to 1 MSS when multiple
=A0 =A0 paths are used? RFC6356 doesn't have this kind of logic. I'= m
=A0 =A0 wondering why this is required. Also, in case of single path, the =A0 =A0 draft requires to set the ssthresh to 2 MSS, but I'm not very s= ure
=A0 =A0 about the rationale behind this.

=A0 =A0 This may be required to avoid the overuse of a congested path
=A0 =A0 whereas other paths are available. If there are many paths, there i= s
=A0 =A0 no use in spoiling media resources with ssthresh set to 2 MSS. I =A0 =A0 guess this parameter is set to 1 MSS to properly only analyze the =A0 =A0 traffic around.

=A0 =A0 The authors may have more explanations than I do.


I personally think setting small ssthresh is not very necessarily,
especially for single path case.
If this is an important point for the logic, I would like to see some
rationale in the draft.
I hope authors will address this in new version.

Thanks,
--
Yoshifumi



--20cf307f31fe870fac04e93d27c0-- --20cf307f31fe870fb104e93d27c2 Content-Type: text/plain; charset=windows-1252; name=Attached Message Part Content-Disposition: attachment; filename=Attached Message Part Content-Transfer-Encoding: base64 X-Attachment-Id: a40c750dfe6fcef0_0.1 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm11bHRpcGF0 aHRjcCBtYWlsaW5nIGxpc3QNCm11bHRpcGF0aHRjcEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWx0aXBhdGh0Y3ANCg0K --20cf307f31fe870fb104e93d27c2-- From ramin@net.t-labs.tu-berlin.de Tue Oct 22 03:19:32 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 3A78311E82F0 for ; Tue, 22 Oct 2013 03:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.114 X-Spam-Level: X-Spam-Status: No, score=-1.114 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1rKQeg6y2C9 for ; Tue, 22 Oct 2013 03:19:31 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id DBE1C11E8240 for ; Tue, 22 Oct 2013 03:19:30 -0700 (PDT) Received: from [130.149.220.44] (ramin.net.t-labs.tu-berlin.de [130.149.220.44]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 161F780025; Tue, 22 Oct 2013 12:19:29 +0200 (CEST) Message-ID: <52665129.8030509@net.t-labs.tu-berlin.de> Date: Tue, 22 Oct 2013 12:19:21 +0200 From: Ramin Khalili User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: multipathtcp@ietf.org, nishida@sfc.wide.ad.jp, philip.eardley@bt.com, Nicolas Kuhn Content-Type: multipart/alternative; boundary="------------030907060601050503010705" Subject: [multipathtcp] new version of draft-khalili-mptcp-congestion-control X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 10:19:32 -0000 This is a multi-part message in MIME format. --------------030907060601050503010705 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Folks, We have updated our draft about the congestion control of MPTCP by applying comments and feedback we received from the members of mptcp WG: http://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control As a summary, in this draft we introduce "Opportunistic Linked-Increases Algorithm" (OLIA) for the congestion control of MPTCP. OLIA has been proposedin our CoNEXT 2012 paper. The extended version of this paper is published at IEEE/ACM ToN 2013.We show in these papers that the currentcongestion control of MPTCP suffers from important performance issues and that OLIA successfully addresses these problems and satisfies the design goal of MPTCP. Recent studies over a wide range of scenarios (including wireless networks)show that MPTCP with OLIA always outperforms MPTCP with LIA and is very responsive to the changes in the environment (see IMC13 and CoNEXT13). These results all confirm that OLIA is an appropriate congestion control for MPTCP. Unfortunately, I could not participate at IETF 88 in Vancouver but I would appreciate if there would be a short discussion during the mptcp WG meeting about how to proceed with this draft. Best regards, Ramin Khalili. [CoNEXT12]: R. Khalili, N. Gast, M. Popovic, U. Upadhyay, J-Y. Le Boudec. "MPTCP is not Pareto-optimal: Performance issues and a possible solution", ACM CoNEXT 2012 (Best Paper) http://conferences.sigcomm.org/co-next/2012/eproceedings/conext/p1.pdf [ToN13]: R. Khalili, N. Gast, M. Popovic, J.-Y. Le Boudec. "MPTCP is not Pareto-optimal: Performance issues and a possible solution", IEEE/ACM Transaction on Networking, Vol. 21, Issue 5, October 2013. http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6583272 [IMC13]: Y.-C. Chih, Y.-S. Lim, R. J. Gibbens, E. Nahum, R. Khalili, and D. Towsley, "A Measurement-based Study of MultiPath TCP Performance over Wireless Networks," long paper atACM IMC 2013. http://conferences.sigcomm.org/imc/2013/papers/imc231-chenA.pdf [CoNEXT13]: C. Paasch, R.Khalili, O. Bonaventure, "On the Benefits of Applying Experimental Design to Improve Multipath TCP", short paper at ACM CoNEXT 2013. http://conferences.sigcomm.org/co-next/2013/program.html (the camera ready would be available in few weeks) --------------030907060601050503010705 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit

Folks,

We have updated our draft about the congestion control of MPTCP by applying comments and feedback we received from the members of mptcp WG:

http://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control

As a summary, in this draft we introduce "Opportunistic Linked-Increases Algorithm" (OLIA) for the congestion control of MPTCP. OLIA has been proposed in our CoNEXT 2012 paper. The extended version of this paper is published at IEEE/ACM ToN 2013. We show in these papers that the current congestion control of MPTCP suffers from important performance issues and that OLIA successfully addresses these problems and satisfies the design goal of MPTCP.

Recent studies over a wide range of scenarios (including wireless networks) show that MPTCP with OLIA always outperforms MPTCP with LIA and is very responsive to the changes in the environment (see IMC13 and CoNEXT13). These results all confirm that OLIA is an appropriate congestion control for MPTCP.

Unfortunately, I could not participate at IETF 88 in Vancouver but I would appreciate if there would be a short discussion during the mptcp WG meeting about how to proceed with this draft.

Best regards,

Ramin Khalili.

[CoNEXT12]: R. Khalili, N. Gast, M. Popovic, U. Upadhyay, J-Y. Le Boudec. "MPTCP is not Pareto-optimal: Performance issues and a possible solution", ACM CoNEXT 2012 (Best Paper)

http://conferences.sigcomm.org/co-next/2012/eproceedings/conext/p1.pdf

[ToN13]: R. Khalili, N. Gast, M. Popovic, J.-Y. Le Boudec. "MPTCP is not Pareto-optimal: Performance issues and a possible solution", IEEE/ACM Transaction on Networking, Vol. 21, Issue 5, October 2013.

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6583272

[IMC13]: Y.-C. Chih, Y.-S. Lim, R. J. Gibbens, E. Nahum, R. Khalili, and D. Towsley, "A Measurement-based Study of MultiPath TCP Performance over Wireless Networks," long paper at ACM IMC 2013.

http://conferences.sigcomm.org/imc/2013/papers/imc231-chenA.pdf

[CoNEXT13]: C. Paasch, R. Khalili, O. Bonaventure, "On the Benefits of Applying Experimental Design to Improve Multipath TCP", short paper at ACM CoNEXT 2013.

http://conferences.sigcomm.org/co-next/2013/program.html
(the camera ready would be available in few weeks) --------------030907060601050503010705-- From nishida@sfc.wide.ad.jp Tue Oct 22 10:51:04 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 688A811E84E3 for ; Tue, 22 Oct 2013 10:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.535 X-Spam-Level: X-Spam-Status: No, score=-101.535 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gm8TlxQh5c3d for ; Tue, 22 Oct 2013 10:51:03 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id EF73A11E84C4 for ; Tue, 22 Oct 2013 10:50:57 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D49762780AC for ; Wed, 23 Oct 2013 02:50:53 +0900 (JST) Received: by mail-lb0-f180.google.com with SMTP id q8so6985532lbi.25 for ; Tue, 22 Oct 2013 10:50:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3CXKwBC3bLwCoXATjhVDuzvrfvzZXJGZSCuQtaJeXLM=; b=ITdLfb9VhIRpjQlU8IptYLOUYWvDpra9vsb40K7UWRLqxGSQH22bDOzWqcPakjxCdG WQE82G6pO1BKiG2n3gdWf3AFGfcAuSqBmbbkcCcqjUfrDN/EFe+qIoDc2V/X8CmPKVJb E0yS1XZJQaq9bIc9YSUlftqXHsnM3CsgVrJQ7zV6W2mNiWYxgKH7nrOc1OMOyFzkfVBs 9ZJgypMBp5HgZNkpDIra0dVkwJiofar1A/WOKuVPqp0hD89Pd/WMiYtad6MFK3l1f1jb n3nBIzfGPZXGLVrssTRR/o5lLgGD1CFuvoSegAPE2zF302ZA5pmkME/F4jnlHr7OI1Ky BCyg== MIME-Version: 1.0 X-Received: by 10.152.3.42 with SMTP id 10mr19204759laz.22.1382464250962; Tue, 22 Oct 2013 10:50:50 -0700 (PDT) Received: by 10.114.99.99 with HTTP; Tue, 22 Oct 2013 10:50:50 -0700 (PDT) In-Reply-To: <52665129.8030509@net.t-labs.tu-berlin.de> References: <52665129.8030509@net.t-labs.tu-berlin.de> Date: Tue, 22 Oct 2013 10:50:50 -0700 Message-ID: From: Yoshifumi Nishida To: Ramin Khalili Content-Type: multipart/alternative; boundary=089e013d14b297ec8004e9580a70 Cc: multipathtcp Subject: Re: [multipathtcp] new version of draft-khalili-mptcp-congestion-control X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 17:51:04 -0000 --089e013d14b297ec8004e9580a70 Content-Type: text/plain; charset=ISO-8859-1 Hi Ramin, OK. Let chairs discuss this. In the meantime, I really appreciate if people express opinions on this. (support, not support, let's wait a bit more, etc) Please note that our current charter does not cover congestion control for multipath transport protocols. I think we will need to re-charter if we want to proceed this. Please let us know if you have comments on this. Thanks, -- Yoshifumi On Tue, Oct 22, 2013 at 3:19 AM, Ramin Khalili < ramin@net.t-labs.tu-berlin.de> wrote: > Folks, > > We have updated our draft about the congestion control of MPTCP by > applying comments and feedback we received from the members of mptcp WG: > http://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control > > As a summary, in this draft we introduce "Opportunistic Linked-Increases > Algorithm" (OLIA) for the congestion control of MPTCP. OLIA has been > proposed in our CoNEXT 2012 paper. The extended version of this paper is > published at IEEE/ACM ToN 2013. We show in these papers that the currentcongestion control of MPTCP suffers from important performance issues and > that OLIA successfully addresses these problems and satisfies the design > goal of MPTCP. > > Recent studies over a wide range of scenarios (including wireless > networks) show that MPTCP with OLIA always outperforms MPTCP with LIA and > is very responsive to the changes in the environment (see IMC13 and > CoNEXT13). These results all confirm that OLIA is an appropriate congestion > control for MPTCP. > > Unfortunately, I could not participate at IETF 88 in Vancouver but I would > appreciate if there would be a short discussion during the mptcp WG meeting > about how to proceed with this draft. > > Best regards, > Ramin Khalili. > > [CoNEXT12]: R. Khalili, N. Gast, M. Popovic, U. Upadhyay, J-Y. Le Boudec. > "MPTCP is not Pareto-optimal: Performance issues and a possible solution", > ACM CoNEXT 2012 (Best Paper) > http://conferences.sigcomm.org/co-next/2012/eproceedings/conext/p1.pdf > > [ToN13]: R. Khalili, N. Gast, M. Popovic, J.-Y. Le Boudec. "MPTCP is not > Pareto-optimal: Performance issues and a possible solution", IEEE/ACM Transaction > on Networking, Vol. 21, Issue 5, October 2013. > http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6583272 > > [IMC13]: Y.-C. Chih, Y.-S. Lim, R. J. Gibbens, E. Nahum, R. Khalili, and > D. Towsley, "A Measurement-based Study of MultiPath TCP Performance over > Wireless Networks," long paper at ACM IMC 2013. > http://conferences.sigcomm.org/imc/2013/papers/imc231-chenA.pdf > > [CoNEXT13]: C. Paasch, R. Khalili, O. Bonaventure, "On the Benefits of > Applying Experimental Design to Improve Multipath TCP", short paper at ACM > CoNEXT 2013. > http://conferences.sigcomm.org/co-next/2013/program.html > (the camera ready would be available in few weeks) > --089e013d14b297ec8004e9580a70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ramin,

OK. Let chairs discuss this.
In the meantime, I really appreciate if people express opinions on this. = (support, not support, let's wait a bit more, etc)
Please note that our current charter does not cover congestion control for = multipath transport protocols.
I think we will need to re-charter if we = want to proceed this. Please let us know if you have comments on this.

Thanks,
--
Yoshifumi


On Tue, Oct 22, 2013 at= 3:19 AM, Ramin Khalili <ramin@net.t-labs.tu-berlin.de>= wrote:
=20 =20 =20
=20

Folks,

We have updated our draft about the congestion control of MPTCP by applying comments and feedback we received from the members of mptcp WG:

http://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-con= trol

As a summary, in this draft we introduce "Opportunistic Linked-Increases Algorithm&quo= t; (OLIA) for the congestion control of MPTCP. OLIA has been proposed in our CoNEXT 2012 paper. The extended version of this paper is published at IEEE/ACM ToN 2013. We show in these papers that the current<= /span> congestion control of MPTCP suffers from important performance issues and that OLIA successfully addresses these problems and satisfies the design goal of MPTCP.

Recent studies over a wide range of scenarios (including wireless networks) show that MPTCP with OLIA always outperforms MPTCP with LIA and is very responsive to the changes in the environment (see IMC13 and CoNEXT13). These results all confirm that OLIA is an appropriate congestion control for MPTCP.

Unfortunately, I could not participate at IETF 88 in Vancouver but I would appreciate if there would be a short discussion during the mptcp WG meeting about how to proceed with this draft.

Best regards,

Ra= min Khalili.

[CoNEXT12]: R. Khalili, N. Gast, M. Popovic, U. Upadhyay, J-Y. Le Boudec. "MPTCP is not Pareto-optimal: Performance issues and a possible solution", ACM CoNEXT 2012 (Best Paper)

http://confe= rences.sigcomm.org/co-next/2012/eproceedings/conext/p1.pdf

[ToN13]: R. Khalili, N. Gast, M. Popovic, J.-Y. Le Boudec. "MPTCP is not Pareto-optimal: Performance issues a= nd a possible solution", IEEE/AC= M Transaction on Networking, Vol. 21, Issue 5, October 2013.

http://ieeexpl= ore.ieee.org/xpl/articleDetails.jsp?arnumber=3D6583272

= = [IMC13]: <= tt>Y= .-C. Chih, Y.-S. Lim, R. J. Gibbens, E. Nahum, R. Khalili, and D. Towsley, "A Measurement-based Study of MultiPath TCP Performance over Wireless Networks," = long paper at <= tt>A= CM IMC 2013.<= font face=3D"Times New Roman, serif">

http://conferences.sigcomm.org/imc/2013/papers/imc231-= chenA.pdf

= = [CoNEXT13]: <= tt>C= . Paasch, R. Khalili, O. Bonaventure, = "On the Benefits of Applying Experimental Design to Improve Multipath TCP", short paper at ACM CoNEXT 2013.

http://conferences.sigcomm.org/co-next/2013/= program.html=
(the camera ready would be available in few weeks) =20 =20 =20

--089e013d14b297ec8004e9580a70-- From nishida@sfc.wide.ad.jp Tue Oct 22 21:53:40 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 6F78011E82D0 for ; Tue, 22 Oct 2013 21:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.904 X-Spam-Level: X-Spam-Status: No, score=-101.904 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujMrwLtm4mQD for ; Tue, 22 Oct 2013 21:53:39 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3D111E811A for ; Tue, 22 Oct 2013 21:53:38 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C95D027807F for ; Wed, 23 Oct 2013 13:53:35 +0900 (JST) Received: by mail-lb0-f180.google.com with SMTP id y6so295459lbh.39 for ; Tue, 22 Oct 2013 21:53:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jBhWFg8SvhoOCvg2dIm0NHk1qX8tvZqoN0U/8vhnq6U=; b=J841VFabunC7JTncsJphTP89dghcXkalj5m+JWzbvGJZg5+Xlrn8RKW8Yt+59Ftktx eDBGrSXVjyLPUpFRnYQUTZGu7ei3Yie6i8Y/UWjFIc/GmHhCdORRg6RoZcJW2YUXTwn9 YCKXoKNwbG/zKn4UbasbmhlQewBGHVC2m3zLy2+CrzwTtvcQV7ZiE/Q9gEaS+Kt+peEn BA4XIRsn6xhKioeo17nuV5cdFbP7Lxj/kzAvfct+7LBpy3mMqpXWR7QpqwKKC5GmS6tv RsHUokvDa5flZbVcQuKp2uNq8jKLAEatYbRLpm60bKNEz6kveZw8b7vJRHhJl2rAJS3r 1l8A== MIME-Version: 1.0 X-Received: by 10.152.116.7 with SMTP id js7mr20381373lab.11.1382504013533; Tue, 22 Oct 2013 21:53:33 -0700 (PDT) Received: by 10.114.99.99 with HTTP; Tue, 22 Oct 2013 21:53:33 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Oct 2013 21:53:33 -0700 Message-ID: From: Yoshifumi Nishida To: Ramin Khalili Content-Type: multipart/alternative; boundary=001a11c2672aa0964e04e9614ce8 Cc: multipathtcp Subject: Re: [multipathtcp] some comments on draft-khalili-mptcp-congestion-control-01 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, 23 Oct 2013 04:53:40 -0000 --001a11c2672aa0964e04e9614ce8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ramin, Nicolas, Thanks for the reply. But, I think I am still a bit confused. Maybe I overlook something... I think I will need to think about Section 3 more carefully. It would be great if you can point out what I'm missing. 1: "The algorithm only applies to the increase part of the congestion avoidance phase." -> It seems to me that OLIA does nothing during slow start phase, which is fine for me. 2: "We also use a similar slow start algorithm as in TCP, with the modification that we set the ssthresh (slow start threshold) to be 1 MSS if multiple paths are established." -> It seems to me that OLIA supports slow-start like algorithm. But, if you set ssthresh to be 1 MSS, I'm not sure how you can activate it. Also, this sounds a bit contradictory to 1: . 3: "In the case of a single path flow, we use the same minimum ssthresh as in TCP (i.e. 2 MSS)." -> I am not very sure how the minimum ssthresh affects OLIA. I guess it will be used only after loss. Thanks, -- Yoshifumi On Mon, Oct 21, 2013 at 2:46 AM, Ramin Khalili wrote: > > Dear Nicolas, Yoshifumi, > > Thanks for your comments and points. We have apply them in our draft and will submit the new version of our draft by this afternoon (I will send a submission notice when the new version is available). > > With regards to the question about ssthresh, as Nicolas said, the main goal is to to avoid the overuse of a congested path whereas other paths are available. > > With Christoph Paasch from UCLouvain, we have done a number of experiments to study the effect of setting the minimum ssthresh to 1. We observed that it improves the load balancing in the network but the gain is not very significant. Note that minimum ssthresh for single path TCP would be still 2 MSS; hence, our modification will not effect the single path TCP performance. > > Cheers, > > Ramin. > > > > > -------- Original Message -------- > Subject: Re: [multipathtcp] some comments on > draft-khalili-mptcp-congestion-control-01 > Date: Thu, 26 Sep 2013 00:32:42 -0700 > From: Yoshifumi Nishida > To: Nicolas Kuhn > CC: multipathtcp > > > > Hi Nicolas, > > Thanks for the response. > > On Mon, Sep 23, 2013 at 12:01 AM, Nicolas Kuhn > wrote: > > Hello, > > Le 23/09/2013 08:00, Yoshifumi Nishida a =E9crit : >> >> Hello, >> I've read draft-khalili-mptcp-congestion-control-01 with great >> interests and have the following comments. Please let me know if I >> miss something. >> >> 1: It seems to me that how to determine collective_paths and >> max_w_paths are a bit ambiguous. Since they are "paths", it seems >> that they are expected to be more than 1. >> However, I'm not very sure about the logic to choose them. For >> example, if 3 paths have >> 10MSS, 20MSS, 30MSS cwnd respectively, do we choose the 20MSS path >> as one of max_w_paths? Or, how about 10MSS, 29MSS, 30MSS case? >> > More details can be found in [5], Section 4.1: Equations (3) and (4) > should be included in the draft. > > > OK. Thanks for the info. > >> 2: Do we really need to set the ssthresh to 1 MSS when multiple >> paths are used? RFC6356 doesn't have this kind of logic. I'm >> wondering why this is required. Also, in case of single path, the >> draft requires to set the ssthresh to 2 MSS, but I'm not very sure >> about the rationale behind this. >> > This may be required to avoid the overuse of a congested path > whereas other paths are available. If there are many paths, there is > no use in spoiling media resources with ssthresh set to 2 MSS. I > guess this parameter is set to 1 MSS to properly only analyze the > traffic around. > > The authors may have more explanations than I do. > > > I personally think setting small ssthresh is not very necessarily, > especially for single path case. > If this is an important point for the logic, I would like to see some > rationale in the draft. > I hope authors will address this in new version. > > Thanks, > -- > Yoshifumi > > > --001a11c2672aa0964e04e9614ce8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ramin, Nicolas,

Thanks for the reply. But, I thi= nk I am still a bit confused. Maybe I overlook something...
I think I wi= ll need to think about Section 3 more carefully. It would be great if you c= an point out what I'm missing.

1: "The algorithm only applies to the increase part of the congest= ion avoidance phase."
=A0 =A0 =A0-> It seems to me that OLIA doe= s nothing during slow start phase, which is fine for me.

2: "We= also use a similar slow start algorithm as in TCP, with the modification t= hat we set the ssthresh (slow start threshold) to be 1 MSS if multiple path= s are established."
=A0 =A0 =A0-> It seems to me that OLIA supports slow-start like algorith= m. But, if you set ssthresh to be 1 MSS, I'm not sure how you can activ= ate it. Also, this sounds a bit contradictory to 1: .

3: =A0"In= the case of a single path flow, we use the same minimum ssthresh=A0as in T= CP (i.e. 2 MSS)."
=A0 =A0 -> I am not very sure how the minimum ssthresh affects OLIA. I g= uess it will be used only after loss.

Thanks,
--
Yoshifumi


On Mon, Oct 21, 2013 at 2:46 AM, Ramin K= halili <raminster@gmail.com&g= t; wrote:
>
> Dear Nicolas, Yoshifumi,
>
> Thanks for your comme= nts and points. We have apply them in our draft and will submit the new ver= sion of our draft by this afternoon (I will send a submission notice when t= he new version is available).
>
> With regards to the question about ssthresh, as Nicolas said, = the main goal is to to avoid the overuse of a congested path whereas other = paths are available.
>
> With Christoph Paasch from UCLouvain,= we have done a number of experiments to study the effect of setting the mi= nimum ssthresh to 1. We observed that it improves the load balancing in the= network but the gain is not very significant. Note that minimum ssthresh f= or single path TCP would be still 2 MSS; hence, our modification will not e= ffect the single path TCP performance.
>
> Cheers,
>
> Ramin. =A0 =A0
>
>
>=
>
> -------- Original Message --------
> Subject: =A0 = =A0 =A0 =A0Re: [multipathtcp] some comments on
> draft-khalili-mptcp-= congestion-control-01
> Date: =A0 Thu, 26 Sep 2013 00:32:42 -0700
> From: =A0 Yoshifumi = Nishida <nishida@sfc.wide.ad.j= p>
> To: =A0 =A0 Nicolas Kuhn <nicolas.kuhn@isae.fr>
> CC: =A0 =A0 multipathtcp <= multipathtcp@ietf.org>
>
>
>
> Hi Nicolas,>
> Thanks for the response.
>
> On Mon, Sep 23, 201= 3 at 12:01 AM, Nicolas Kuhn <nic= olas.kuhn@isae.fr
> <mailto:nicolas.kuhn@isae.f= r>> wrote:
>
> =A0 =A0 Hello,
>
> =A0 =A0= Le 23/09/2013 08:00, Yoshifumi Nishida a =E9crit :
>>
>>= =A0 =A0 Hello,
>> =A0 =A0 I've read draft-khalili-mptcp-congestion-control-01 wi= th great
>> =A0 =A0 interests and have the following comments. Ple= ase let me know if I
>> =A0 =A0 miss something.
>>
>= ;> =A0 =A0 1: It seems to me that how to determine collective_paths and<= br> >> =A0 =A0 max_w_paths are a bit ambiguous. Since they are "path= s", it seems
>> =A0 =A0 that they are expected to be more tha= n 1.
>> =A0 =A0 However, I'm not very sure about the logic to = choose them. For
>> =A0 =A0 example, if 3 paths have
>> =A0 =A0 10MSS, 20MSS,= 30MSS cwnd respectively, do we choose the 20MSS path
>> =A0 =A0 a= s one of max_w_paths? Or, how about 10MSS, 29MSS, 30MSS case?
>>> =A0 =A0 More details can be found in [5], Section 4.1: Equations (3)= and (4)
> =A0 =A0 should be included in the draft.
>
>
> OK. T= hanks for the info.
>
>> =A0 =A0 2: Do we really need to set= the ssthresh to 1 MSS when multiple
>> =A0 =A0 paths are used? RF= C6356 doesn't have this kind of logic. I'm
>> =A0 =A0 wondering why this is required. Also, in case of single pa= th, the
>> =A0 =A0 draft requires to set the ssthresh to 2 MSS, bu= t I'm not very sure
>> =A0 =A0 about the rationale behind this= .
>>
> =A0 =A0 This may be required to avoid the overuse of a congested path<= br>> =A0 =A0 whereas other paths are available. If there are many paths,= there is
> =A0 =A0 no use in spoiling media resources with ssthresh = set to 2 MSS. I
> =A0 =A0 guess this parameter is set to 1 MSS to properly only analyze = the
> =A0 =A0 traffic around.
>
> =A0 =A0 The authors may= have more explanations than I do.
>
>
> I personally thi= nk setting small ssthresh is not very necessarily,
> especially for single path case.
> If this is an important point= for the logic, I would like to see some
> rationale in the draft.> I hope authors will address this in new version.
>
> Than= ks,
> --
> Yoshifumi
>
>
>
--001a11c2672aa0964e04e9614ce8-- From Nicolas.Kuhn@isae.fr Wed Oct 23 01:09:40 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 3F83F11E8327 for ; Wed, 23 Oct 2013 01:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yx2ySNzgE5JE for ; Wed, 23 Oct 2013 01:09:34 -0700 (PDT) Received: from smtpext.isae.fr (smtpext.isae.fr [193.54.120.4]) by ietfa.amsl.com (Postfix) with ESMTP id CEAD111E8307 for ; Wed, 23 Oct 2013 01:09:32 -0700 (PDT) Received: from catalpa (unknown [10.4.1.11]) by smtpext.isae.fr (Postfix) with ESMTP id A409322E405; Wed, 23 Oct 2013 10:09:27 +0200 (CEST) Received: from webmail.isae.fr (alisier.isae.fr [193.54.120.24]) by catalpa (Postfix) with ESMTP id 1D7D2B7D5E; Wed, 23 Oct 2013 10:09:31 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 23 Oct 2013 10:09:31 +0200 From: KUHN Nicolas To: Yoshifumi Nishida In-Reply-To: References: Message-ID: <8e4dbeafcbd15d32d40cf3ff14dd94e9@merisier.isae.fr> X-Sender: Nicolas.Kuhn@isae.fr User-Agent: Roundcube ISAE Webmail/0.7.1 Cc: multipathtcp , Ramin Khalili Subject: Re: [multipathtcp] some comments on draft-khalili-mptcp-congestion-control-01 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, 23 Oct 2013 08:09:40 -0000 Hi all, Please find my comments in your email, and let me know if I am wrong about my understanding of the draft and your questions. Le 23/10/2013 06:53, Yoshifumi Nishida a écrit : > Hi Ramin, Nicolas, > > Thanks for the reply. But, I think I am still a bit confused. Maybe I > overlook something... > I think I will need to think about Section 3 more carefully. It would > be great if you can point out what I'm missing. > > 1: "The algorithm only applies to the increase part of the congestion > avoidance phase." > -> It seems to me that OLIA does nothing during slow start > phase, which is fine for me. > The algorithm behind OLIA congestion windows updates must be introduced in congestion avoidance phase. And the slow start phase should be the same as TCP. I agree with you on that point. > 2: "We also use a similar slow start algorithm as in TCP, with the > modification that we set the ssthresh (slow start threshold) to be 1 > MSS if multiple paths are established." > -> It seems to me that OLIA supports slow-start like algorithm. > But, if you set ssthresh to be 1 MSS, I'm not sure how you can activate > it. Also, this sounds a bit contradictory to 1: . > Here comes the confusion. Setting ssthresh to be 1 MSS means that there is no slow start phase: the congestion window is always greater than 1MSS! I guess there is a mistake in the current draft and I propose the following changes: 1- precise that, as for common TCP, the ssthresh is initialized to "infinity"; 2- replace ssthresh hold in this section by "initial congestion window" or "minimum congestion window". > 3: "In the case of a single path flow, we use the same minimum > ssthresh as in TCP (i.e. 2 MSS)." > -> I am not very sure how the minimum ssthresh affects OLIA. I > guess it will be used only after loss. As previously mentioned, I guess this confusion comes from the fact that ssthresh has been used (instead of minimum congestion window). Let me know if I am wrong. If I am right, I think it is important to adapt the draft regarding this issue. Kind regards, Nicolas > Thanks, > -- > Yoshifumi > > > On Mon, Oct 21, 2013 at 2:46 AM, Ramin Khalili > wrote: > > > > Dear Nicolas, Yoshifumi, > > > > Thanks for your comments and points. We have apply them in our > draft and will submit the new version of our draft by this afternoon (I > will send a submission notice when the new version is available). > > > > With regards to the question about ssthresh, as Nicolas said, the > main goal is to to avoid the overuse of a congested path whereas other > paths are available. > > > > With Christoph Paasch from UCLouvain, we have done a number of > experiments to study the effect of setting the minimum ssthresh to 1. > We observed that it improves the load balancing in the network but the > gain is not very significant. Note that minimum ssthresh for single > path TCP would be still 2 MSS; hence, our modification will not effect > the single path TCP performance. > > > > Cheers, > > > > Ramin. > > > > > > > > > > -------- Original Message -------- > > Subject: Re: [multipathtcp] some comments on > > draft-khalili-mptcp-congestion-control-01 > > Date: Thu, 26 Sep 2013 00:32:42 -0700 > > From: Yoshifumi Nishida > > To: Nicolas Kuhn > > CC: multipathtcp > > > > > > > > Hi Nicolas, > > > > Thanks for the response. > > > > On Mon, Sep 23, 2013 at 12:01 AM, Nicolas Kuhn > > > wrote: > > > > Hello, > > > > Le 23/09/2013 08:00, Yoshifumi Nishida a écrit : > >> > >> Hello, > >> I've read draft-khalili-mptcp-congestion-control-01 with great > >> interests and have the following comments. Please let me know > if I > >> miss something. > >> > >> 1: It seems to me that how to determine collective_paths and > >> max_w_paths are a bit ambiguous. Since they are "paths", it > seems > >> that they are expected to be more than 1. > >> However, I'm not very sure about the logic to choose them. For > >> example, if 3 paths have > >> 10MSS, 20MSS, 30MSS cwnd respectively, do we choose the 20MSS > path > >> as one of max_w_paths? Or, how about 10MSS, 29MSS, 30MSS case? > >> > > More details can be found in [5], Section 4.1: Equations (3) > and (4) > > should be included in the draft. > > > > > > OK. Thanks for the info. > > > >> 2: Do we really need to set the ssthresh to 1 MSS when > multiple > >> paths are used? RFC6356 doesn't have this kind of logic. I'm > >> wondering why this is required. Also, in case of single path, > the > >> draft requires to set the ssthresh to 2 MSS, but I'm not very > sure > >> about the rationale behind this. > >> > > This may be required to avoid the overuse of a congested path > > whereas other paths are available. If there are many paths, > there is > > no use in spoiling media resources with ssthresh set to 2 MSS. > I > > guess this parameter is set to 1 MSS to properly only analyze > the > > traffic around. > > > > The authors may have more explanations than I do. > > > > > > I personally think setting small ssthresh is not very necessarily, > > especially for single path case. > > If this is an important point for the logic, I would like to see > some > > rationale in the draft. > > I hope authors will address this in new version. > > > > Thanks, > > -- > > Yoshifumi > > > > > > From christoph.paasch@uclouvain.be Wed Oct 23 01:29: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 E14C621E809A for ; Wed, 23 Oct 2013 01:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcVFKNhwDeqI for ; Wed, 23 Oct 2013 01:29:48 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 37FCC21E8082 for ; Wed, 23 Oct 2013 01:29:48 -0700 (PDT) Received: from localhost (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id DA1C0183445; Wed, 23 Oct 2013 10:29:37 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be DA1C0183445 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1382516977; bh=Pw4HEQ302/J/p2Mj0KJTgbHJkPZcVaNj2Pfo9Tq+Kwg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=pIZUNbWHbqRo2+Q7rQP7ZPD4pz827N/jd2AfDdvXFetPG87vrWVkUHPUty/z2oLq3 +9H637nkvbgHGNgI94UXgmNcmMVqyZSSYfhlbZAX5LYBS6AQ9nseia0I2qZ8n4bDxD 9Hn96aRXKN4J/XAQFRyLRlLGURREPzG4YbXgQMWY= Date: Wed, 23 Oct 2013 10:29:37 +0200 From: Christoph Paasch To: KUHN Nicolas Message-ID: <20131023082937.GA5132@cpaasch-mac> References: <8e4dbeafcbd15d32d40cf3ff14dd94e9@merisier.isae.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8e4dbeafcbd15d32d40cf3ff14dd94e9@merisier.isae.fr> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: DA1C0183445.A1DDE X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp , Ramin Khalili Subject: Re: [multipathtcp] some comments on draft-khalili-mptcp-congestion-control-01 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, 23 Oct 2013 08:29:53 -0000 Hello, On 23/10/13 - 10:09:31, KUHN Nicolas wrote: > Le 23/10/2013 06:53, Yoshifumi Nishida a écrit : > >Thanks for the reply. But, I think I am still a bit confused. > >Maybe I overlook something... > >I think I will need to think about Section 3 more carefully. It > >would be great if you can point out what I'm missing. > > > >1: "The algorithm only applies to the increase part of the > >congestion avoidance phase." > > -> It seems to me that OLIA does nothing during slow start > >phase, which is fine for me. > > > The algorithm behind OLIA congestion windows updates must be > introduced in congestion avoidance phase. And the slow start phase > should be the same as TCP. I agree with you on that point. > > >2: "We also use a similar slow start algorithm as in TCP, with the > >modification that we set the ssthresh (slow start threshold) to be > >1 MSS if multiple paths are established." > > -> It seems to me that OLIA supports slow-start like > >algorithm. But, if you set ssthresh to be 1 MSS, I'm not sure how > >you can activate it. Also, this sounds a bit contradictory to 1: . > > > Here comes the confusion. Setting ssthresh to be 1 MSS means that > there is no slow start phase: the congestion window is always > greater than 1MSS! > I guess there is a mistake in the current draft and I propose the > following changes: > 1- precise that, as for common TCP, the ssthresh is initialized to > "infinity"; > 2- replace ssthresh hold in this section by "initial congestion > window" or "minimum congestion window". the setting of ssthresh to 1 is done, when subsequent losses make the ssthresh come down to 2. In regular TCP, if a loss happens and ssthresh equals 2, it will not set it to 1, but leave it at 2. However, with Ramin's proposal it will set it to 1, effectively allowing a sending-rate of 1 packet per RTT. The text probably needs to be changed to reflect this. Cheers, Christoph > >3: "In the case of a single path flow, we use the same minimum > >ssthresh as in TCP (i.e. 2 MSS)." > > -> I am not very sure how the minimum ssthresh affects OLIA. I > >guess it will be used only after loss. > As previously mentioned, I guess this confusion comes from the fact > that ssthresh has been used (instead of minimum congestion window). > Let me know if I am wrong. > If I am right, I think it is important to adapt the draft regarding > this issue. > > Kind regards, > > Nicolas > > >Thanks, > >-- > >Yoshifumi > > > > > >On Mon, Oct 21, 2013 at 2:46 AM, Ramin Khalili > > wrote: > >> > >> Dear Nicolas, Yoshifumi, > >> > >> Thanks for your comments and points. We have apply them in our > >draft and will submit the new version of our draft by this > >afternoon (I will send a submission notice when the new version is > >available). > >> > >> With regards to the question about ssthresh, as Nicolas said, > >the main goal is to to avoid the overuse of a congested path > >whereas other paths are available. > >> > >> With Christoph Paasch from UCLouvain, we have done a number of > >experiments to study the effect of setting the minimum ssthresh to > >1. We observed that it improves the load balancing in the network > >but the gain is not very significant. Note that minimum ssthresh > >for single path TCP would be still 2 MSS; hence, our modification > >will not effect the single path TCP performance. > >> > >> Cheers, > >> > >> Ramin. > >> > >> > >> > >> > >> -------- Original Message -------- > >> Subject: Re: [multipathtcp] some comments on > >> draft-khalili-mptcp-congestion-control-01 > >> Date: Thu, 26 Sep 2013 00:32:42 -0700 > >> From: Yoshifumi Nishida > >> To: Nicolas Kuhn > >> CC: multipathtcp > >> > >> > >> > >> Hi Nicolas, > >> > >> Thanks for the response. > >> > >> On Mon, Sep 23, 2013 at 12:01 AM, Nicolas Kuhn > > >> > wrote: > >> > >> Hello, > >> > >> Le 23/09/2013 08:00, Yoshifumi Nishida a écrit : > >>> > >>> Hello, > >>> I've read draft-khalili-mptcp-congestion-control-01 with great > >>> interests and have the following comments. Please let me > >know if I > >>> miss something. > >>> > >>> 1: It seems to me that how to determine collective_paths and > >>> max_w_paths are a bit ambiguous. Since they are "paths", it > >seems > >>> that they are expected to be more than 1. > >>> However, I'm not very sure about the logic to choose them. For > >>> example, if 3 paths have > >>> 10MSS, 20MSS, 30MSS cwnd respectively, do we choose the > >20MSS path > >>> as one of max_w_paths? Or, how about 10MSS, 29MSS, 30MSS case? > >>> > >> More details can be found in [5], Section 4.1: Equations (3) > >and (4) > >> should be included in the draft. > >> > >> > >> OK. Thanks for the info. > >> > >>> 2: Do we really need to set the ssthresh to 1 MSS when > >multiple > >>> paths are used? RFC6356 doesn't have this kind of logic. I'm > >>> wondering why this is required. Also, in case of single > >path, the > >>> draft requires to set the ssthresh to 2 MSS, but I'm not > >very sure > >>> about the rationale behind this. > >>> > >> This may be required to avoid the overuse of a congested path > >> whereas other paths are available. If there are many paths, > >there is > >> no use in spoiling media resources with ssthresh set to 2 > >MSS. I > >> guess this parameter is set to 1 MSS to properly only > >analyze the > >> traffic around. > >> > >> The authors may have more explanations than I do. > >> > >> > >> I personally think setting small ssthresh is not very necessarily, > >> especially for single path case. > >> If this is an important point for the logic, I would like to see > >some > >> rationale in the draft. > >> I hope authors will address this in new version. > >> > >> Thanks, > >> -- > >> Yoshifumi > >> > >> > >> > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From ramin@net.t-labs.tu-berlin.de Wed Oct 23 07:00: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 815BE11E83B1 for ; Wed, 23 Oct 2013 07:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzVlGbYKc7n1 for ; Wed, 23 Oct 2013 07:00:45 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id B510111E837C for ; Wed, 23 Oct 2013 07:00:41 -0700 (PDT) Received: from [192.168.5.204] (60.Red-83-45-112.dynamicIP.rima-tde.net [83.45.112.60]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id CB86480B78; Wed, 23 Oct 2013 16:00:40 +0200 (CEST) Message-ID: <5267D685.4050102@net.t-labs.tu-berlin.de> Date: Wed, 23 Oct 2013 16:00:37 +0200 From: Ramin Khalili User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Christoph Paasch , KUHN Nicolas References: <8e4dbeafcbd15d32d40cf3ff14dd94e9@merisier.isae.fr> <20131023082937.GA5132@cpaasch-mac> In-Reply-To: <20131023082937.GA5132@cpaasch-mac> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: multipathtcp Subject: Re: [multipathtcp] some comments on draft-khalili-mptcp-congestion-control-01 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, 23 Oct 2013 14:00:46 -0000 Hi Yoshifumi, As Nicolas and Christoph said, the motivation behind this modification is to be less aggressive over a very lossy path. TCP new-reno uses ssthresh to decide if the user is in slow start or congestion avoidance phase (if cwnd =< ssthresh we are in slow start, o.w. congestion avoidance). Note that cwnd increases much faster during the slow start phase than congestion avoidance. To have a good load balancing in the network, we should not use paths that have very bad performance. If we use minimum ssthresh of 2 MSS, cwnd would be almost always greater than 3MSS on a path even if the path is very lossy (because slow start is more aggressive than congestion avoidance). This results to a minimum traffic rate of 3MSS/RTT over a path which is very high. By our modification, we allow the minimum traffic rate over a path be as small as 1MSS/RTT. Note that we do not change the minimum value of cwnd and similarly to TCP new-reno it is set to 1MSS. Also, this modification will not affect good paths (as for these paths, the probability that ssthresh become 1MSS is very small). Also, we apply this modification only if more than one path is available to the user, hence, it does not affect the performance of single path connections. I would add some discussion in the draft about why and how this modification is applied. I am wondering if I can upload the new version after the modification? Best regards, Ramin. Am 23.10.2013 10:29, schrieb Christoph Paasch: > Hello, > > On 23/10/13 - 10:09:31, KUHN Nicolas wrote: >> Le 23/10/2013 06:53, Yoshifumi Nishida a écrit : >>> Thanks for the reply. But, I think I am still a bit confused. >>> Maybe I overlook something... >>> I think I will need to think about Section 3 more carefully. It >>> would be great if you can point out what I'm missing. >>> >>> 1: "The algorithm only applies to the increase part of the >>> congestion avoidance phase." >>> -> It seems to me that OLIA does nothing during slow start >>> phase, which is fine for me. >>> >> The algorithm behind OLIA congestion windows updates must be >> introduced in congestion avoidance phase. And the slow start phase >> should be the same as TCP. I agree with you on that point. >> >>> 2: "We also use a similar slow start algorithm as in TCP, with the >>> modification that we set the ssthresh (slow start threshold) to be >>> 1 MSS if multiple paths are established." >>> -> It seems to me that OLIA supports slow-start like >>> algorithm. But, if you set ssthresh to be 1 MSS, I'm not sure how >>> you can activate it. Also, this sounds a bit contradictory to 1: . >>> >> Here comes the confusion. Setting ssthresh to be 1 MSS means that >> there is no slow start phase: the congestion window is always >> greater than 1MSS! >> I guess there is a mistake in the current draft and I propose the >> following changes: >> 1- precise that, as for common TCP, the ssthresh is initialized to >> "infinity"; >> 2- replace ssthresh hold in this section by "initial congestion >> window" or "minimum congestion window". > the setting of ssthresh to 1 is done, when subsequent losses make the > ssthresh come down to 2. In regular TCP, if a loss happens and ssthresh > equals 2, it will not set it to 1, but leave it at 2. > However, with Ramin's proposal it will set it to 1, effectively allowing > a sending-rate of 1 packet per RTT. > > The text probably needs to be changed to reflect this. > > > Cheers, > Christoph > >>> 3: "In the case of a single path flow, we use the same minimum >>> ssthresh as in TCP (i.e. 2 MSS)." >>> -> I am not very sure how the minimum ssthresh affects OLIA. I >>> guess it will be used only after loss. >> As previously mentioned, I guess this confusion comes from the fact >> that ssthresh has been used (instead of minimum congestion window). >> Let me know if I am wrong. >> If I am right, I think it is important to adapt the draft regarding >> this issue. >> >> Kind regards, >> >> Nicolas >> >>> Thanks, >>> -- >>> Yoshifumi >>> >>> >>> On Mon, Oct 21, 2013 at 2:46 AM, Ramin Khalili >>> wrote: >>>> Dear Nicolas, Yoshifumi, >>>> >>>> Thanks for your comments and points. We have apply them in our >>> draft and will submit the new version of our draft by this >>> afternoon (I will send a submission notice when the new version is >>> available). >>>> With regards to the question about ssthresh, as Nicolas said, >>> the main goal is to to avoid the overuse of a congested path >>> whereas other paths are available. >>>> With Christoph Paasch from UCLouvain, we have done a number of >>> experiments to study the effect of setting the minimum ssthresh to >>> 1. We observed that it improves the load balancing in the network >>> but the gain is not very significant. Note that minimum ssthresh >>> for single path TCP would be still 2 MSS; hence, our modification >>> will not effect the single path TCP performance. >>>> Cheers, >>>> >>>> Ramin. >>>> >>>> >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: Re: [multipathtcp] some comments on >>>> draft-khalili-mptcp-congestion-control-01 >>>> Date: Thu, 26 Sep 2013 00:32:42 -0700 >>>> From: Yoshifumi Nishida >>>> To: Nicolas Kuhn >>>> CC: multipathtcp >>>> >>>> >>>> >>>> Hi Nicolas, >>>> >>>> Thanks for the response. >>>> >>>> On Mon, Sep 23, 2013 at 12:01 AM, Nicolas Kuhn >>> >>> > wrote: >>>> >>>> Hello, >>>> >>>> Le 23/09/2013 08:00, Yoshifumi Nishida a écrit : >>>>> Hello, >>>>> I've read draft-khalili-mptcp-congestion-control-01 with great >>>>> interests and have the following comments. Please let me >>> know if I >>>>> miss something. >>>>> >>>>> 1: It seems to me that how to determine collective_paths and >>>>> max_w_paths are a bit ambiguous. Since they are "paths", it >>> seems >>>>> that they are expected to be more than 1. >>>>> However, I'm not very sure about the logic to choose them. For >>>>> example, if 3 paths have >>>>> 10MSS, 20MSS, 30MSS cwnd respectively, do we choose the >>> 20MSS path >>>>> as one of max_w_paths? Or, how about 10MSS, 29MSS, 30MSS case? >>>>> >>>> More details can be found in [5], Section 4.1: Equations (3) >>> and (4) >>>> should be included in the draft. >>>> >>>> >>>> OK. Thanks for the info. >>>> >>>>> 2: Do we really need to set the ssthresh to 1 MSS when >>> multiple >>>>> paths are used? RFC6356 doesn't have this kind of logic. I'm >>>>> wondering why this is required. Also, in case of single >>> path, the >>>>> draft requires to set the ssthresh to 2 MSS, but I'm not >>> very sure >>>>> about the rationale behind this. >>>>> >>>> This may be required to avoid the overuse of a congested path >>>> whereas other paths are available. If there are many paths, >>> there is >>>> no use in spoiling media resources with ssthresh set to 2 >>> MSS. I >>>> guess this parameter is set to 1 MSS to properly only >>> analyze the >>>> traffic around. >>>> >>>> The authors may have more explanations than I do. >>>> >>>> >>>> I personally think setting small ssthresh is not very necessarily, >>>> especially for single path case. >>>> If this is an important point for the logic, I would like to see >>> some >>>> rationale in the draft. >>>> I hope authors will address this in new version. >>>> >>>> Thanks, >>>> -- >>>> Yoshifumi >>>> >>>> >>>> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From ramin@net.t-labs.tu-berlin.de Wed Oct 23 07:14:13 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 3DDFF11E8399 for ; Wed, 23 Oct 2013 07:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObNbHP8RZHDn for ; Wed, 23 Oct 2013 07:14:12 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id CF0FE11E8382 for ; Wed, 23 Oct 2013 07:14:11 -0700 (PDT) Received: from [192.168.5.204] (60.Red-83-45-112.dynamicIP.rima-tde.net [83.45.112.60]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 8628A80374; Wed, 23 Oct 2013 16:14:10 +0200 (CEST) Message-ID: <5267D9AE.5090302@net.t-labs.tu-berlin.de> Date: Wed, 23 Oct 2013 16:14:06 +0200 From: Ramin Khalili User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Yoshifumi Nishida References: <52665129.8030509@net.t-labs.tu-berlin.de> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060108000007020303020801" Cc: multipathtcp Subject: Re: [multipathtcp] new version of draft-khalili-mptcp-congestion-control 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, 23 Oct 2013 14:14:13 -0000 This is a multi-part message in MIME format. --------------060108000007020303020801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Yoshifumi, During the IETF meeting in Berlin, I have discussed with Fred Baker, Olivier Bonaventure, and Philip Eardley about this draft. The general feedback was that congestion control is an important part of MPTCP and OLIA seems to be an appropriate solution, so it should be discussed in the group. The question was how to fit it into the agenda. It would be really great if other folks can also express their opinion about how to proceed with this draft. Best regards, Ramin. Am 22.10.2013 19:50, schrieb Yoshifumi Nishida: > Hi Ramin, > > OK. Let chairs discuss this. > In the meantime, I really appreciate if people express opinions on > this. (support, not support, let's wait a bit more, etc) > Please note that our current charter does not cover congestion control > for multipath transport protocols. > I think we will need to re-charter if we want to proceed this. Please > let us know if you have comments on this. > > Thanks, > -- > Yoshifumi > > > On Tue, Oct 22, 2013 at 3:19 AM, Ramin Khalili > > > wrote: > > Folks, > > We have updated our draft about the congestion control of MPTCP by > applying comments and feedback we received from the members of > mptcp WG: > > http://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control > > > As a summary, in this draft we introduce "Opportunistic > Linked-Increases Algorithm" (OLIA) for the congestion control of > MPTCP. OLIA has been proposedin our CoNEXT 2012 paper. The > extended version of this paper is published at IEEE/ACM ToN > 2013.We show in these papers that the currentcongestion control of > MPTCP suffers from important performance issues and that OLIA > successfully addresses these problems and satisfies the design > goal of MPTCP. > > Recent studies over a wide range of scenarios (including wireless > networks)show that MPTCP with OLIA always outperforms MPTCP with > LIA and is very responsive to the changes in the environment (see > IMC13 and CoNEXT13). These results all confirm that OLIA is an > appropriate congestion control for MPTCP. > > Unfortunately, I could not participate at IETF 88 in Vancouver but > I would appreciate if there would be a short discussion during the > mptcp WG meeting about how to proceed with this draft. > > Best regards, > > Ramin Khalili. > > [CoNEXT12]: R. Khalili, N. Gast, M. Popovic, U. Upadhyay, J-Y. Le > Boudec. "MPTCP is not Pareto-optimal: Performance issues and a > possible solution", ACM CoNEXT 2012 (Best Paper) > > http://conferences.sigcomm.org/co-next/2012/eproceedings/conext/p1.pdf > > > [ToN13]: R. Khalili, N. Gast, M. Popovic, J.-Y. Le Boudec. "MPTCP > is not Pareto-optimal: Performance issues and a possible > solution", IEEE/ACM Transaction on Networking, Vol. 21, Issue 5, > October 2013. > > http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6583272 > > [IMC13]: Y.-C. Chih, Y.-S. Lim, R. J. Gibbens, E. Nahum, R. > Khalili, and D. Towsley, "A Measurement-based Study of MultiPath > TCP Performance over Wireless Networks," long paper atACM IMC 2013. > > http://conferences.sigcomm.org/imc/2013/papers/imc231-chenA.pdf > > [CoNEXT13]: C. Paasch, R.Khalili, O. Bonaventure, "On the Benefits > of Applying Experimental Design to Improve Multipath TCP", short > paper at ACM CoNEXT 2013. > > http://conferences.sigcomm.org/co-next/2013/program.html > (the camera ready would be available in few weeks) > > --------------060108000007020303020801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Yoshifumi,

During the IETF meeting in Berlin, I have discussed with Fred Baker, Olivier Bonaventure, and Philip Eardley about this draft. The general feedback was that congestion control is an important part of MPTCP and OLIA seems to be an appropriate solution, so it should be discussed in the group. The question was how to fit it into the agenda.

It would be really great if other folks can also express their opinion about how to proceed with this draft.

Best regards,
Ramin.


Am 22.10.2013 19:50, schrieb Yoshifumi Nishida:
Hi Ramin,

OK. Let chairs discuss this.
In the meantime, I really appreciate if people express opinions on this. (support, not support, let's wait a bit more, etc)
Please note that our current charter does not cover congestion control for multipath transport protocols.
I think we will need to re-charter if we want to proceed this. Please let us know if you have comments on this.

Thanks,
--
Yoshifumi


On Tue, Oct 22, 2013 at 3:19 AM, Ramin Khalili <ramin@net.t-labs.tu-berlin.de> wrote:

Folks,

We have updated our draft about the congestion control of MPTCP by applying comments and feedback we received from the members of mptcp WG:

http://datatracker.ietf.org/doc/draft-khalili-mptcp-congestion-control

As a summary, in this draft we introduce "Opportunistic Linked-Increases Algorithm" (OLIA) for the congestion control of MPTCP. OLIA has been proposed in our CoNEXT 2012 paper. The extended version of this paper is published at IEEE/ACM ToN 2013. We show in these papers that the current congestion control of MPTCP suffers from important performance issues and that OLIA successfully addresses these problems and satisfies the design goal of MPTCP.

Recent studies over a wide range of scenarios (including wireless networks) show that MPTCP with OLIA always outperforms MPTCP with LIA and is very responsive to the changes in the environment (see IMC13 and CoNEXT13). These results all confirm that OLIA is an appropriate congestion control for MPTCP.

Unfortunately, I could not participate at IETF 88 in Vancouver but I would appreciate if there would be a short discussion during the mptcp WG meeting about how to proceed with this draft.

Best regards,

Ramin Khalili.

[CoNEXT12]: R. Khalili, N. Gast, M. Popovic, U. Upadhyay, J-Y. Le Boudec. "MPTCP is not Pareto-optimal: Performance issues and a possible solution", ACM CoNEXT 2012 (Best Paper)

http://conferences.sigcomm.org/co-next/2012/eproceedings/conext/p1.pdf

[ToN13]: R. Khalili, N. Gast, M. Popovic, J.-Y. Le Boudec. "MPTCP is not Pareto-optimal: Performance issues and a possible solution", IEEE/ACM Transaction on Networking, Vol. 21, Issue 5, October 2013.

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6583272

[IMC13]: Y.-C. Chih, Y.-S. Lim, R. J. Gibbens, E. Nahum, R. Khalili, and D. Towsley, "A Measurement-based Study of MultiPath TCP Performance over Wireless Networks," long paper at ACM IMC 2013.

http://conferences.sigcomm.org/imc/2013/papers/imc231-chenA.pdf

[CoNEXT13]: C. Paasch, R. Khalili, O. Bonaventure, "On the Benefits of Applying Experimental Design to Improve Multipath TCP", short paper at ACM CoNEXT 2013.

http://conferences.sigcomm.org/co-next/2013/program.html
(the camera ready would be available in few weeks)


--------------060108000007020303020801-- From ramin@net.t-labs.tu-berlin.de Wed Oct 23 07:34: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 A85AE11E837F for ; Wed, 23 Oct 2013 07:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0G+suOwkT4j for ; Wed, 23 Oct 2013 07:34:56 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id AF25611E81BD for ; Wed, 23 Oct 2013 07:34:51 -0700 (PDT) Received: from [192.168.5.204] (60.Red-83-45-112.dynamicIP.rima-tde.net [83.45.112.60]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id D197080AD2; Wed, 23 Oct 2013 16:34:46 +0200 (CEST) Message-ID: <5267DE81.1050600@net.t-labs.tu-berlin.de> Date: Wed, 23 Oct 2013 16:34:41 +0200 From: Ramin Khalili User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: KUHN Nicolas , Yoshifumi Nishida References: <8e4dbeafcbd15d32d40cf3ff14dd94e9@merisier.isae.fr> In-Reply-To: <8e4dbeafcbd15d32d40cf3ff14dd94e9@merisier.isae.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: multipathtcp , Ramin Khalili Subject: Re: [multipathtcp] some comments on draft-khalili-mptcp-congestion-control-01 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, 23 Oct 2013 14:34:57 -0000 Nicolas, OLIA uses the same slow start mechanism as TCP, it also uses the same mechanism as TCP to update ssthresh. The only difference is that with TCP, ssthresh cannot be smaller than 2MSS but with OLIA it can be 1 MSS. Roughly saying, when a loss occurs TCP divides the cwnd by half, i.e. cwnd = cwnd_old /2, and set ssthresh = max (min_ssthresh, cwnd_old/2). cwnd_old is the value of cwnd right before observing the loss. For TCP, min_ssthresh is 2 MSS. OLIA uses exactly the same algorithm as TCP but with min_ssthresh = 1. I must note that the mechanism that is used by TCP (and OLIA) to determine ssthresh is a bit more complex than what I explained above. Cheers, Ramin. Am 23.10.2013 10:09, schrieb KUHN Nicolas: > Hi all, > > Please find my comments in your email, and let me know if I am wrong > about my understanding of the draft and your questions. > > Le 23/10/2013 06:53, Yoshifumi Nishida a écrit : >> Hi Ramin, Nicolas, >> >> Thanks for the reply. But, I think I am still a bit confused. Maybe I >> overlook something... >> I think I will need to think about Section 3 more carefully. It would >> be great if you can point out what I'm missing. >> >> 1: "The algorithm only applies to the increase part of the congestion >> avoidance phase." >> -> It seems to me that OLIA does nothing during slow start >> phase, which is fine for me. >> > The algorithm behind OLIA congestion windows updates must be > introduced in congestion avoidance phase. And the slow start phase > should be the same as TCP. I agree with you on that point. > >> 2: "We also use a similar slow start algorithm as in TCP, with the >> modification that we set the ssthresh (slow start threshold) to be 1 >> MSS if multiple paths are established." >> -> It seems to me that OLIA supports slow-start like algorithm. >> But, if you set ssthresh to be 1 MSS, I'm not sure how you can >> activate it. Also, this sounds a bit contradictory to 1: . >> > Here comes the confusion. Setting ssthresh to be 1 MSS means that > there is no slow start phase: the congestion window is always greater > than 1MSS! > I guess there is a mistake in the current draft and I propose the > following changes: > 1- precise that, as for common TCP, the ssthresh is initialized to > "infinity"; > 2- replace ssthresh hold in this section by "initial congestion > window" or "minimum congestion window". > >> 3: "In the case of a single path flow, we use the same minimum >> ssthresh as in TCP (i.e. 2 MSS)." >> -> I am not very sure how the minimum ssthresh affects OLIA. I >> guess it will be used only after loss. > As previously mentioned, I guess this confusion comes from the fact > that ssthresh has been used (instead of minimum congestion window). > Let me know if I am wrong. > If I am right, I think it is important to adapt the draft regarding > this issue. > > Kind regards, > > Nicolas > >> Thanks, >> -- >> Yoshifumi >> >> >> On Mon, Oct 21, 2013 at 2:46 AM, Ramin Khalili >> wrote: >> > >> > Dear Nicolas, Yoshifumi, >> > >> > Thanks for your comments and points. We have apply them in our >> draft and will submit the new version of our draft by this afternoon >> (I will send a submission notice when the new version is available). >> > >> > With regards to the question about ssthresh, as Nicolas said, the >> main goal is to to avoid the overuse of a congested path whereas >> other paths are available. >> > >> > With Christoph Paasch from UCLouvain, we have done a number of >> experiments to study the effect of setting the minimum ssthresh to 1. >> We observed that it improves the load balancing in the network but >> the gain is not very significant. Note that minimum ssthresh for >> single path TCP would be still 2 MSS; hence, our modification will >> not effect the single path TCP performance. >> > >> > Cheers, >> > >> > Ramin. >> > >> > >> > >> > >> > -------- Original Message -------- >> > Subject: Re: [multipathtcp] some comments on >> > draft-khalili-mptcp-congestion-control-01 >> > Date: Thu, 26 Sep 2013 00:32:42 -0700 >> > From: Yoshifumi Nishida >> > To: Nicolas Kuhn >> > CC: multipathtcp >> > >> > >> > >> > Hi Nicolas, >> > >> > Thanks for the response. >> > >> > On Mon, Sep 23, 2013 at 12:01 AM, Nicolas Kuhn > > > wrote: >> > >> > Hello, >> > >> > Le 23/09/2013 08:00, Yoshifumi Nishida a écrit : >> >> >> >> Hello, >> >> I've read draft-khalili-mptcp-congestion-control-01 with great >> >> interests and have the following comments. Please let me know >> if I >> >> miss something. >> >> >> >> 1: It seems to me that how to determine collective_paths and >> >> max_w_paths are a bit ambiguous. Since they are "paths", it seems >> >> that they are expected to be more than 1. >> >> However, I'm not very sure about the logic to choose them. For >> >> example, if 3 paths have >> >> 10MSS, 20MSS, 30MSS cwnd respectively, do we choose the 20MSS >> path >> >> as one of max_w_paths? Or, how about 10MSS, 29MSS, 30MSS case? >> >> >> > More details can be found in [5], Section 4.1: Equations (3) >> and (4) >> > should be included in the draft. >> > >> > >> > OK. Thanks for the info. >> > >> >> 2: Do we really need to set the ssthresh to 1 MSS when multiple >> >> paths are used? RFC6356 doesn't have this kind of logic. I'm >> >> wondering why this is required. Also, in case of single path, the >> >> draft requires to set the ssthresh to 2 MSS, but I'm not very >> sure >> >> about the rationale behind this. >> >> >> > This may be required to avoid the overuse of a congested path >> > whereas other paths are available. If there are many paths, >> there is >> > no use in spoiling media resources with ssthresh set to 2 MSS. I >> > guess this parameter is set to 1 MSS to properly only analyze the >> > traffic around. >> > >> > The authors may have more explanations than I do. >> > >> > >> > I personally think setting small ssthresh is not very necessarily, >> > especially for single path case. >> > If this is an important point for the logic, I would like to see some >> > rationale in the draft. >> > I hope authors will address this in new version. >> > >> > Thanks, >> > -- >> > Yoshifumi >> > >> > >> > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nishida@sfc.wide.ad.jp Thu Oct 24 01:26:40 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 274EF11E812D for ; Thu, 24 Oct 2013 01:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.081 X-Spam-Level: X-Spam-Status: No, score=-101.081 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEQ90j+OYOLB for ; Thu, 24 Oct 2013 01:26:38 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 315C421E808C for ; Thu, 24 Oct 2013 01:26:33 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 07A30278091 for ; Thu, 24 Oct 2013 17:26:30 +0900 (JST) Received: by mail-la0-f49.google.com with SMTP id eh20so1569193lab.22 for ; Thu, 24 Oct 2013 01:26:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O2LlE51eHl9JmLidrDSHJcRg/KMEBmBG7cWKO+qeLUg=; b=ZZQIK+1S78cp/jwch6SAyOgTTBL8sGKcy5tkKrMKqzsA7GtUNmUZYRlChjQbwK5e7Z iCl06Qa1hTh6FIENKxBKN9UDV77LrqU5usYdsBtnB0iPq+f8mn2Ql1TCaXAYhvcLK6pZ 5IvNGWHm1c8VmD5e18kPDHhzCDDS42qaTe8iedKfsA23WzYwVSEtlQCvhcajddV9mY/A ZwNuKA5IGopXDW1QeM6/t05IW1JTeZ2WLetv9jrdRdcvFXkmJaQ7E0x90Jor5DDj3KpG TThnq6Hav0T4vdoEXRr9owsSVZp+zZRmCHb4syJ+d6WMUGGM9Ijs1N+hdXY45/sC3Pm2 9dbw== MIME-Version: 1.0 X-Received: by 10.112.135.104 with SMTP id pr8mr1228061lbb.34.1382603188667; Thu, 24 Oct 2013 01:26:28 -0700 (PDT) Received: by 10.114.99.99 with HTTP; Thu, 24 Oct 2013 01:26:28 -0700 (PDT) In-Reply-To: <5267D685.4050102@net.t-labs.tu-berlin.de> References: <8e4dbeafcbd15d32d40cf3ff14dd94e9@merisier.isae.fr> <20131023082937.GA5132@cpaasch-mac> <5267D685.4050102@net.t-labs.tu-berlin.de> Date: Thu, 24 Oct 2013 01:26:28 -0700 Message-ID: From: Yoshifumi Nishida To: Ramin Khalili Content-Type: multipart/alternative; boundary=089e01228936ed0c2d04e9786356 Cc: multipathtcp Subject: Re: [multipathtcp] some comments on draft-khalili-mptcp-congestion-control-01 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, 24 Oct 2013 08:26:40 -0000 --089e01228936ed0c2d04e9786356 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ramin, Christoph, Nicolas, Thanks for the clarification. I just thought OLIA uses low ssthresh at the beginning of the connection when I read the text, but now I think I understand. I think I still need to understand how using 1 MSS for minimum ssthresh can affect the performance. I'm hoping you will add some discussions on this point in the new version. Thanks, -- Yoshifumi On Wed, Oct 23, 2013 at 7:00 AM, Ramin Khalili < ramin@net.t-labs.tu-berlin.de> wrote: > Hi Yoshifumi, > > As Nicolas and Christoph said, the motivation behind this modification is > to be less aggressive over a very lossy path. TCP new-reno uses ssthresh = to > decide if the user is in slow start or congestion avoidance phase (if cwn= d > =3D< ssthresh we are in slow start, o.w. congestion avoidance). Note that > cwnd increases much faster during the slow start phase than congestion > avoidance. > > To have a good load balancing in the network, we should not use paths tha= t > have very bad performance. If we use minimum ssthresh of 2 MSS, cwnd woul= d > be almost always greater than 3MSS on a path even if the path is very los= sy > (because slow start is more aggressive than congestion avoidance). This > results to a minimum traffic rate of 3MSS/RTT over a path which is very > high. > > By our modification, we allow the minimum traffic rate over a path be as > small as 1MSS/RTT. Note that we do not change the minimum value of cwnd a= nd > similarly to TCP new-reno it is set to 1MSS. Also, this modification will > not affect good paths (as for these paths, the probability that ssthresh > become 1MSS is very small). Also, we apply this modification only if more > than one path is available to the user, hence, it does not affect the > performance of single path connections. > > I would add some discussion in the draft about why and how this > modification is applied. I am wondering if I can upload the new version > after the modification? > > Best regards, > Ramin. > > > > Am 23.10.2013 10:29, schrieb Christoph Paasch: > > Hello, >> >> On 23/10/13 - 10:09:31, KUHN Nicolas wrote: >> >>> Le 23/10/2013 06:53, Yoshifumi Nishida a =E9crit : >>> >>>> Thanks for the reply. But, I think I am still a bit confused. >>>> Maybe I overlook something... >>>> I think I will need to think about Section 3 more carefully. It >>>> would be great if you can point out what I'm missing. >>>> >>>> 1: "The algorithm only applies to the increase part of the >>>> congestion avoidance phase." >>>> -> It seems to me that OLIA does nothing during slow start >>>> phase, which is fine for me. >>>> >>>> The algorithm behind OLIA congestion windows updates must be >>> introduced in congestion avoidance phase. And the slow start phase >>> should be the same as TCP. I agree with you on that point. >>> >>> 2: "We also use a similar slow start algorithm as in TCP, with the >>>> modification that we set the ssthresh (slow start threshold) to be >>>> 1 MSS if multiple paths are established." >>>> -> It seems to me that OLIA supports slow-start like >>>> algorithm. But, if you set ssthresh to be 1 MSS, I'm not sure how >>>> you can activate it. Also, this sounds a bit contradictory to 1: . >>>> >>>> Here comes the confusion. Setting ssthresh to be 1 MSS means that >>> there is no slow start phase: the congestion window is always >>> greater than 1MSS! >>> I guess there is a mistake in the current draft and I propose the >>> following changes: >>> 1- precise that, as for common TCP, the ssthresh is initialized to >>> "infinity"; >>> 2- replace ssthresh hold in this section by "initial congestion >>> window" or "minimum congestion window". >>> >> the setting of ssthresh to 1 is done, when subsequent losses make the >> ssthresh come down to 2. In regular TCP, if a loss happens and ssthresh >> equals 2, it will not set it to 1, but leave it at 2. >> However, with Ramin's proposal it will set it to 1, effectively allowing >> a sending-rate of 1 packet per RTT. >> >> The text probably needs to be changed to reflect this. >> >> >> Cheers, >> Christoph >> >> 3: "In the case of a single path flow, we use the same minimum >>>> ssthresh as in TCP (i.e. 2 MSS)." >>>> -> I am not very sure how the minimum ssthresh affects OLIA. I >>>> guess it will be used only after loss. >>>> >>> As previously mentioned, I guess this confusion comes from the fact >>> that ssthresh has been used (instead of minimum congestion window). >>> Let me know if I am wrong. >>> If I am right, I think it is important to adapt the draft regarding >>> this issue. >>> >>> Kind regards, >>> >>> Nicolas >>> >>> Thanks, >>>> -- >>>> Yoshifumi >>>> >>>> >>>> On Mon, Oct 21, 2013 at 2:46 AM, Ramin Khalili >>>> wrote: >>>> >>>>> Dear Nicolas, Yoshifumi, >>>>> >>>>> Thanks for your comments and points. We have apply them in our >>>>> >>>> draft and will submit the new version of our draft by this >>>> afternoon (I will send a submission notice when the new version is >>>> available). >>>> >>>>> With regards to the question about ssthresh, as Nicolas said, >>>>> >>>> the main goal is to to avoid the overuse of a congested path >>>> whereas other paths are available. >>>> >>>>> With Christoph Paasch from UCLouvain, we have done a number of >>>>> >>>> experiments to study the effect of setting the minimum ssthresh to >>>> 1. We observed that it improves the load balancing in the network >>>> but the gain is not very significant. Note that minimum ssthresh >>>> for single path TCP would be still 2 MSS; hence, our modification >>>> will not effect the single path TCP performance. >>>> >>>>> Cheers, >>>>> >>>>> Ramin. >>>>> >>>>> >>>>> >>>>> >>>>> -------- Original Message -------- >>>>> Subject: Re: [multipathtcp] some comments on >>>>> draft-khalili-mptcp-**congestion-control-01 >>>>> Date: Thu, 26 Sep 2013 00:32:42 -0700 >>>>> From: Yoshifumi Nishida >>>>> To: Nicolas Kuhn >>>>> CC: multipathtcp >>>>> >>>>> >>>>> >>>>> Hi Nicolas, >>>>> >>>>> Thanks for the response. >>>>> >>>>> On Mon, Sep 23, 2013 at 12:01 AM, Nicolas Kuhn >>>>> >>>> >>> >>>>> > wrote: >>>>> >>>>> Hello, >>>>> >>>>> Le 23/09/2013 08:00, Yoshifumi Nishida a =E9crit : >>>>> >>>>>> Hello, >>>>>> I've read draft-khalili-mptcp-**congestion-control-01 with grea= t >>>>>> interests and have the following comments. Please let me >>>>>> >>>>> know if I >>>> >>>>> miss something. >>>>>> >>>>>> 1: It seems to me that how to determine collective_paths and >>>>>> max_w_paths are a bit ambiguous. Since they are "paths", it >>>>>> >>>>> seems >>>> >>>>> that they are expected to be more than 1. >>>>>> However, I'm not very sure about the logic to choose them. For >>>>>> example, if 3 paths have >>>>>> 10MSS, 20MSS, 30MSS cwnd respectively, do we choose the >>>>>> >>>>> 20MSS path >>>> >>>>> as one of max_w_paths? Or, how about 10MSS, 29MSS, 30MSS case? >>>>>> >>>>>> More details can be found in [5], Section 4.1: Equations (3) >>>>> >>>> and (4) >>>> >>>>> should be included in the draft. >>>>> >>>>> >>>>> OK. Thanks for the info. >>>>> >>>>> 2: Do we really need to set the ssthresh to 1 MSS when >>>>>> >>>>> multiple >>>> >>>>> paths are used? RFC6356 doesn't have this kind of logic. I'm >>>>>> wondering why this is required. Also, in case of single >>>>>> >>>>> path, the >>>> >>>>> draft requires to set the ssthresh to 2 MSS, but I'm not >>>>>> >>>>> very sure >>>> >>>>> about the rationale behind this. >>>>>> >>>>>> This may be required to avoid the overuse of a congested path >>>>> whereas other paths are available. If there are many paths, >>>>> >>>> there is >>>> >>>>> no use in spoiling media resources with ssthresh set to 2 >>>>> >>>> MSS. I >>>> >>>>> guess this parameter is set to 1 MSS to properly only >>>>> >>>> analyze the >>>> >>>>> traffic around. >>>>> >>>>> The authors may have more explanations than I do. >>>>> >>>>> >>>>> I personally think setting small ssthresh is not very necessarily, >>>>> especially for single path case. >>>>> If this is an important point for the logic, I would like to see >>>>> >>>> some >>>> >>>>> rationale in the draft. >>>>> I hope authors will address this in new version. >>>>> >>>>> Thanks, >>>>> -- >>>>> Yoshifumi >>>>> >>>>> >>>>> >>>>> ______________________________**_________________ >>> 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 >> > > --089e01228936ed0c2d04e9786356 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ramin, Christoph, Nicolas,

Thanks fo= r the clarification.
I just thought OLIA uses low ssthresh at the b= eginning of the connection when I read the text, but now I think I understa= nd.
I think I still need to understand how usin= g 1 MSS for minimum ssthresh can affect the performance.
I'm hoping you will add some discussions on this point in= the new version.

Thanks,
--
Yoshifumi= =A0

On Wed, Oct 23, 2013 at 7:00 AM, Rami= n Khalili <ramin@net.t-labs.tu-berlin.de> wrote:=
Hi Yoshifumi,

As Nicolas and Christoph said, the motivation behind this modification is t= o be less aggressive over a very lossy path. TCP new-reno uses ssthresh to = decide if the user is in slow start or congestion avoidance phase (if cwnd = =3D< ssthresh we are in slow start, o.w. congestion avoidance). Note tha= t cwnd increases much faster during the slow start phase than congestion av= oidance.

To have a good load balancing in the network, we should not use paths that = have very bad performance. If we use minimum ssthresh of 2 MSS, cwnd would = be almost always greater than 3MSS on a path even if the path is very lossy= (because slow start is more aggressive than congestion avoidance). This re= sults to a minimum traffic rate of 3MSS/RTT over a path which is very high.=

By our modification, we allow the minimum traffic rate over a path be as sm= all as 1MSS/RTT. Note that we do not change the minimum value of cwnd and s= imilarly to TCP new-reno it is set to 1MSS. Also, this modification will no= t affect good paths (as for these paths, the probability that ssthresh beco= me 1MSS is very small). Also, we apply this modification only if more than = one path is available to the user, hence, it does not affect the performanc= e of single path connections.

I would add some discussion in the draft about why and how this modificatio= n is applied. I am wondering if I can upload the new version after the modi= fication?

Best regards,
Ramin.



Am 23.10.2013 10:29, schrieb Christoph Paasch:

Hello,

On 23/10/13 - 10:09:31, KUHN Nicolas wrote:
Le 23/10/2013 06:53, Yoshifumi Nishida a =E9crit :
Thanks for the reply. But, I think I am still a bit confused.
Maybe I overlook something...
I think I will need to think about Section 3 more carefully. It
would be great if you can point out what I'm missing.

1: "The algorithm only applies to the increase part of the
congestion avoidance phase."
=A0 =A0 =A0-> It seems to me that OLIA does nothing during slow start phase, which is fine for me.

The algorithm behind OLIA congestion windows updates must be
introduced in congestion avoidance phase. And the slow start phase
should be the same as TCP. I agree with you on that point.

2: "We also use a similar slow start algorithm as in TCP, with the
modification that we set the ssthresh (slow start threshold) to be
1 MSS if multiple paths are established."
=A0 =A0 =A0-> It seems to me that OLIA supports slow-start like
algorithm. But, if you set ssthresh to be 1 MSS, I'm not sure how
you can activate it. Also, this sounds a bit contradictory to 1: .

Here comes the confusion. Setting ssthresh to be 1 MSS means that
there is no slow start phase: the congestion window is always
greater than 1MSS!
I guess there is a mistake in the current draft and I propose the
following changes:
1- precise that, as for common TCP, the ssthresh is initialized to
"infinity";
2- replace ssthresh hold in this section by "initial congestion
window" or "minimum congestion window".
the setting of ssthresh to 1 is done, when subsequent losses make the
ssthresh come down to 2. In regular TCP, if a loss happens and ssthresh
equals 2, it will not set it to 1, but leave it at 2.
However, with Ramin's proposal it will set it to 1, effectively allowin= g
a sending-rate of 1 packet per RTT.

The text probably needs to be changed to reflect this.


Cheers,
Christoph

3: =A0"In the case of a single path flow, we use the same minimum
ssthresh as in TCP (i.e. 2 MSS)."
=A0 =A0 -> I am not very sure how the minimum ssthresh affects OLIA. I guess it will be used only after loss.
As previously mentioned, I guess this confusion comes from the fact
that ssthresh has been used (instead of minimum congestion window).
Let me know if I am wrong.
If I am right, I think it is important to adapt the draft regarding
this issue.

Kind regards,

Nicolas

Thanks,
--
Yoshifumi


On Mon, Oct 21, 2013 at 2:46 AM, Ramin Khalili
<raminster@gmai= l.com> wrote:
Dear Nicolas, Yoshifumi,

Thanks for your comments and points. We have apply them in our
draft and will submit the new version of our draft by this
afternoon (I will send a submission notice when the new version is
available).
With regards to the question about ssthresh, as Nicolas said,
the main goal is to to avoid the overuse of a congested path
whereas other paths are available.
With Christoph Paasch from UCLouvain, we have done a number of
experiments to study the effect of setting the minimum ssthresh to
1. We observed that it improves the load balancing in the network
but the gain is not very significant. Note that minimum ssthresh
for single path TCP would be still 2 MSS; hence, our modification
will not effect the single path TCP performance.
Cheers,

Ramin.




-------- Original Message --------
Subject: =A0 =A0 =A0 =A0Re: [multipathtcp] some comments on
draft-khalili-mptcp-congestion-control-01
Date: =A0 Thu, 26 Sep 2013 00:32:42 -0700
From: =A0 Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
To: =A0 =A0 Nicolas Kuhn <nicolas.kuhn@isae.fr>
CC: =A0 =A0 multipathtcp <multipathtcp@ietf.org>



Hi Nicolas,

Thanks for the response.

On Mon, Sep 23, 2013 at 12:01 AM, Nicolas Kuhn
<nicolas.kuhn@= isae.fr
<mailto:nicola= s.kuhn@isae.fr>> wrote:

=A0 =A0 =A0Hello,

=A0 =A0 =A0Le 23/09/2013 08:00, Yoshifumi Nishida a =E9crit :
=A0 =A0 =A0Hello,
=A0 =A0 =A0I've read draft-khalili-mptcp-congestion-control-01 w= ith great
=A0 =A0 =A0interests and have the following comments. Please let me
know if I
=A0 =A0 =A0miss something.

=A0 =A0 =A01: It seems to me that how to determine collective_paths and
=A0 =A0 =A0max_w_paths are a bit ambiguous. Since they are "paths"= ;, it
seems
=A0 =A0 =A0that they are expected to be more than 1.
=A0 =A0 =A0However, I'm not very sure about the logic to choose them. F= or
=A0 =A0 =A0example, if 3 paths have
=A0 =A0 =A010MSS, 20MSS, 30MSS cwnd respectively, do we choose the
20MSS path
=A0 =A0 =A0as one of max_w_paths? Or, how about 10MSS, 29MSS, 30MSS case?
=A0 =A0 =A0More details can be found in [5], Section 4.1: Equations (3)
and (4)
=A0 =A0 =A0should be included in the draft.


OK. Thanks for the info.

=A0 =A0 =A02: Do we really need to set the ssthresh to 1 MSS when
multiple
=A0 =A0 =A0paths are used? RFC6356 doesn't have this kind of logic. I&#= 39;m
=A0 =A0 =A0wondering why this is required. Also, in case of single
path, the
=A0 =A0 =A0draft requires to set the ssthresh to 2 MSS, but I'm not
very sure
=A0 =A0 =A0about the rationale behind this.

=A0 =A0 =A0This may be required to avoid the overuse of a congested path =A0 =A0 =A0whereas other paths are available. If there are many paths,
there is
=A0 =A0 =A0no use in spoiling media resources with ssthresh set to 2
MSS. I
=A0 =A0 =A0guess this parameter is set to 1 MSS to properly only
analyze the
=A0 =A0 =A0traffic around.

=A0 =A0 =A0The authors may have more explanations than I do.


I personally think setting small ssthresh is not very necessarily,
especially for single path case.
If this is an important point for the logic, I would like to see
some
rationale in the draft.
I hope authors will address this in new version.

Thanks,
--
Yoshifumi



_______________________________________________
multipathtcp mailing list
multipathtcp@iet= f.org
https://www.ietf.org/mailman/listinfo/multipathtcp
_______________________________________________
multipathtcp mailing list
multipathtcp@iet= f.org
https://www.ietf.org/mailman/listinfo/multipathtcp


--089e01228936ed0c2d04e9786356-- From ramin@net.t-labs.tu-berlin.de Thu Oct 24 05:10:49 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 19BFC11E8143 for ; Thu, 24 Oct 2013 05:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.932 X-Spam-Level: X-Spam-Status: No, score=-0.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByMZ1phdkx0Z for ; Thu, 24 Oct 2013 05:10:47 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id DE37D11E814C for ; Thu, 24 Oct 2013 05:10:44 -0700 (PDT) Received: from [192.168.0.12] (255.Red-81-33-48.dynamicIP.rima-tde.net [81.33.48.255]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id AD6DA80AE0; Thu, 24 Oct 2013 14:10:41 +0200 (CEST) Date: Thu, 24 Oct 2013 14:10:38 +0200 Message-ID: Importance: normal From: ramin To: nishida@sfc.wide.ad.jp MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_497684347424200" Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] some comments on draft-khalili-mptcp-congestion-control-01 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ramin List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 12:10:49 -0000 ----_com.android.email_497684347424200 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 U3VyZSwgSSB3aWxsIGFkZCBhIGRpc2N1c3Npb24gcGFydCBhYm91dCB0aGlzIG1vZGlmaWNhdGlv biBhbmQgd2lsbCB1ZGF0ZSB0aGUgbmV3IHZlcnNpb24uCgpSZWdhcmRzLApSYW1pbi4KCgoKLS0t LS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQpGcm9tOiBZb3NoaWZ1bWkgTmlzaGlkYSA8 bmlzaGlkYUBzZmMud2lkZS5hZC5qcD4gCkRhdGU6ICAKVG86IFJhbWluIEtoYWxpbGkgPHJhbWlu QG5ldC50LWxhYnMudHUtYmVybGluLmRlPiAKQ2M6IENocmlzdG9waCBQYWFzY2ggPGNocmlzdG9w aC5wYWFzY2hAdWNsb3V2YWluLmJlPixLVUhOIE5pY29sYXMgPE5pY29sYXMuS3VobkBpc2FlLmZy PixtdWx0aXBhdGh0Y3AgPG11bHRpcGF0aHRjcEBpZXRmLm9yZz4sWW9zaGlmdW1pIE5pc2hpZGEg PG5pc2hpZGFAc2ZjLndpZGUuYWQuanA+IApTdWJqZWN0OiBSZTogW211bHRpcGF0aHRjcF0gc29t ZSBjb21tZW50cyBvbiBkcmFmdC1raGFsaWxpLW1wdGNwLWNvbmdlc3Rpb24tY29udHJvbC0wMSAK IApIaSBSYW1pbiwgQ2hyaXN0b3BoLCBOaWNvbGFzLAoKVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNh dGlvbi4KSSBqdXN0IHRob3VnaHQgT0xJQSB1c2VzIGxvdyBzc3RocmVzaCBhdCB0aGUgYmVnaW5u aW5nIG9mIHRoZSBjb25uZWN0aW9uIHdoZW4gSSByZWFkIHRoZSB0ZXh0LCBidXQgbm93IEkgdGhp bmsgSSB1bmRlcnN0YW5kLgpJIHRoaW5rIEkgc3RpbGwgbmVlZCB0byB1bmRlcnN0YW5kIGhvdyB1 c2luZyAxIE1TUyBmb3IgbWluaW11bSBzc3RocmVzaCBjYW4gYWZmZWN0IHRoZSBwZXJmb3JtYW5j ZS4KSSdtIGhvcGluZyB5b3Ugd2lsbCBhZGQgc29tZSBkaXNjdXNzaW9ucyBvbiB0aGlzIHBvaW50 IGluIHRoZSBuZXcgdmVyc2lvbi4KClRoYW5rcywKLS0KWW9zaGlmdW1pwqAKCk9uIFdlZCwgT2N0 IDIzLCAyMDEzIGF0IDc6MDAgQU0sIFJhbWluIEtoYWxpbGkgPHJhbWluQG5ldC50LWxhYnMudHUt YmVybGluLmRlPiB3cm90ZToKSGkgWW9zaGlmdW1pLAoKQXMgTmljb2xhcyBhbmQgQ2hyaXN0b3Bo IHNhaWQsIHRoZSBtb3RpdmF0aW9uIGJlaGluZCB0aGlzIG1vZGlmaWNhdGlvbiBpcyB0byBiZSBs ZXNzIGFnZ3Jlc3NpdmUgb3ZlciBhIHZlcnkgbG9zc3kgcGF0aC4gVENQIG5ldy1yZW5vIHVzZXMg c3N0aHJlc2ggdG8gZGVjaWRlIGlmIHRoZSB1c2VyIGlzIGluIHNsb3cgc3RhcnQgb3IgY29uZ2Vz dGlvbiBhdm9pZGFuY2UgcGhhc2UgKGlmIGN3bmQgPTwgc3N0aHJlc2ggd2UgYXJlIGluIHNsb3cg c3RhcnQsIG8udy4gY29uZ2VzdGlvbiBhdm9pZGFuY2UpLiBOb3RlIHRoYXQgY3duZCBpbmNyZWFz ZXMgbXVjaCBmYXN0ZXIgZHVyaW5nIHRoZSBzbG93IHN0YXJ0IHBoYXNlIHRoYW4gY29uZ2VzdGlv biBhdm9pZGFuY2UuCgpUbyBoYXZlIGEgZ29vZCBsb2FkIGJhbGFuY2luZyBpbiB0aGUgbmV0d29y aywgd2Ugc2hvdWxkIG5vdCB1c2UgcGF0aHMgdGhhdCBoYXZlIHZlcnkgYmFkIHBlcmZvcm1hbmNl LiBJZiB3ZSB1c2UgbWluaW11bSBzc3RocmVzaCBvZiAyIE1TUywgY3duZCB3b3VsZCBiZSBhbG1v c3QgYWx3YXlzIGdyZWF0ZXIgdGhhbiAzTVNTIG9uIGEgcGF0aCBldmVuIGlmIHRoZSBwYXRoIGlz IHZlcnkgbG9zc3kgKGJlY2F1c2Ugc2xvdyBzdGFydCBpcyBtb3JlIGFnZ3Jlc3NpdmUgdGhhbiBj b25nZXN0aW9uIGF2b2lkYW5jZSkuIFRoaXMgcmVzdWx0cyB0byBhIG1pbmltdW0gdHJhZmZpYyBy YXRlIG9mIDNNU1MvUlRUIG92ZXIgYSBwYXRoIHdoaWNoIGlzIHZlcnkgaGlnaC4KCkJ5IG91ciBt b2RpZmljYXRpb24sIHdlIGFsbG93IHRoZSBtaW5pbXVtIHRyYWZmaWMgcmF0ZSBvdmVyIGEgcGF0 aCBiZSBhcyBzbWFsbCBhcyAxTVNTL1JUVC4gTm90ZSB0aGF0IHdlIGRvIG5vdCBjaGFuZ2UgdGhl IG1pbmltdW0gdmFsdWUgb2YgY3duZCBhbmQgc2ltaWxhcmx5IHRvIFRDUCBuZXctcmVubyBpdCBp cyBzZXQgdG8gMU1TUy4gQWxzbywgdGhpcyBtb2RpZmljYXRpb24gd2lsbCBub3QgYWZmZWN0IGdv b2QgcGF0aHMgKGFzIGZvciB0aGVzZSBwYXRocywgdGhlIHByb2JhYmlsaXR5IHRoYXQgc3N0aHJl c2ggYmVjb21lIDFNU1MgaXMgdmVyeSBzbWFsbCkuIEFsc28sIHdlIGFwcGx5IHRoaXMgbW9kaWZp Y2F0aW9uIG9ubHkgaWYgbW9yZSB0aGFuIG9uZSBwYXRoIGlzIGF2YWlsYWJsZSB0byB0aGUgdXNl ciwgaGVuY2UsIGl0IGRvZXMgbm90IGFmZmVjdCB0aGUgcGVyZm9ybWFuY2Ugb2Ygc2luZ2xlIHBh dGggY29ubmVjdGlvbnMuCgpJIHdvdWxkIGFkZCBzb21lIGRpc2N1c3Npb24gaW4gdGhlIGRyYWZ0 IGFib3V0IHdoeSBhbmQgaG93IHRoaXMgbW9kaWZpY2F0aW9uIGlzIGFwcGxpZWQuIEkgYW0gd29u ZGVyaW5nIGlmIEkgY2FuIHVwbG9hZCB0aGUgbmV3IHZlcnNpb24gYWZ0ZXIgdGhlIG1vZGlmaWNh dGlvbj8KCkJlc3QgcmVnYXJkcywKUmFtaW4uCgoKCkFtIDIzLjEwLjIwMTMgMTA6MjksIHNjaHJp ZWIgQ2hyaXN0b3BoIFBhYXNjaDoKCkhlbGxvLAoKT24gMjMvMTAvMTMgLSAxMDowOTozMSwgS1VI TiBOaWNvbGFzIHdyb3RlOgpMZSAyMy8xMC8yMDEzIDA2OjUzLCBZb3NoaWZ1bWkgTmlzaGlkYSBh IMOpY3JpdCA6ClRoYW5rcyBmb3IgdGhlIHJlcGx5LiBCdXQsIEkgdGhpbmsgSSBhbSBzdGlsbCBh IGJpdCBjb25mdXNlZC4KTWF5YmUgSSBvdmVybG9vayBzb21ldGhpbmcuLi4KSSB0aGluayBJIHdp bGwgbmVlZCB0byB0aGluayBhYm91dCBTZWN0aW9uIDMgbW9yZSBjYXJlZnVsbHkuIEl0CndvdWxk IGJlIGdyZWF0IGlmIHlvdSBjYW4gcG9pbnQgb3V0IHdoYXQgSSdtIG1pc3NpbmcuCgoxOiAiVGhl IGFsZ29yaXRobSBvbmx5IGFwcGxpZXMgdG8gdGhlIGluY3JlYXNlIHBhcnQgb2YgdGhlCmNvbmdl c3Rpb24gYXZvaWRhbmNlIHBoYXNlLiIKwqAgwqAgwqAtPiBJdCBzZWVtcyB0byBtZSB0aGF0IE9M SUEgZG9lcyBub3RoaW5nIGR1cmluZyBzbG93IHN0YXJ0CnBoYXNlLCB3aGljaCBpcyBmaW5lIGZv ciBtZS4KClRoZSBhbGdvcml0aG0gYmVoaW5kIE9MSUEgY29uZ2VzdGlvbiB3aW5kb3dzIHVwZGF0 ZXMgbXVzdCBiZQppbnRyb2R1Y2VkIGluIGNvbmdlc3Rpb24gYXZvaWRhbmNlIHBoYXNlLiBBbmQg dGhlIHNsb3cgc3RhcnQgcGhhc2UKc2hvdWxkIGJlIHRoZSBzYW1lIGFzIFRDUC4gSSBhZ3JlZSB3 aXRoIHlvdSBvbiB0aGF0IHBvaW50LgoKMjogIldlIGFsc28gdXNlIGEgc2ltaWxhciBzbG93IHN0 YXJ0IGFsZ29yaXRobSBhcyBpbiBUQ1AsIHdpdGggdGhlCm1vZGlmaWNhdGlvbiB0aGF0IHdlIHNl dCB0aGUgc3N0aHJlc2ggKHNsb3cgc3RhcnQgdGhyZXNob2xkKSB0byBiZQoxIE1TUyBpZiBtdWx0 aXBsZSBwYXRocyBhcmUgZXN0YWJsaXNoZWQuIgrCoCDCoCDCoC0+IEl0IHNlZW1zIHRvIG1lIHRo YXQgT0xJQSBzdXBwb3J0cyBzbG93LXN0YXJ0IGxpa2UKYWxnb3JpdGhtLiBCdXQsIGlmIHlvdSBz ZXQgc3N0aHJlc2ggdG8gYmUgMSBNU1MsIEknbSBub3Qgc3VyZSBob3cKeW91IGNhbiBhY3RpdmF0 ZSBpdC4gQWxzbywgdGhpcyBzb3VuZHMgYSBiaXQgY29udHJhZGljdG9yeSB0byAxOiAuCgpIZXJl IGNvbWVzIHRoZSBjb25mdXNpb24uIFNldHRpbmcgc3N0aHJlc2ggdG8gYmUgMSBNU1MgbWVhbnMg dGhhdAp0aGVyZSBpcyBubyBzbG93IHN0YXJ0IHBoYXNlOiB0aGUgY29uZ2VzdGlvbiB3aW5kb3cg aXMgYWx3YXlzCmdyZWF0ZXIgdGhhbiAxTVNTIQpJIGd1ZXNzIHRoZXJlIGlzIGEgbWlzdGFrZSBp biB0aGUgY3VycmVudCBkcmFmdCBhbmQgSSBwcm9wb3NlIHRoZQpmb2xsb3dpbmcgY2hhbmdlczoK MS0gcHJlY2lzZSB0aGF0LCBhcyBmb3IgY29tbW9uIFRDUCwgdGhlIHNzdGhyZXNoIGlzIGluaXRp YWxpemVkIHRvCiJpbmZpbml0eSI7CjItIHJlcGxhY2Ugc3N0aHJlc2ggaG9sZCBpbiB0aGlzIHNl Y3Rpb24gYnkgImluaXRpYWwgY29uZ2VzdGlvbgp3aW5kb3ciIG9yICJtaW5pbXVtIGNvbmdlc3Rp b24gd2luZG93Ii4KdGhlIHNldHRpbmcgb2Ygc3N0aHJlc2ggdG8gMSBpcyBkb25lLCB3aGVuIHN1 YnNlcXVlbnQgbG9zc2VzIG1ha2UgdGhlCnNzdGhyZXNoIGNvbWUgZG93biB0byAyLiBJbiByZWd1 bGFyIFRDUCwgaWYgYSBsb3NzIGhhcHBlbnMgYW5kIHNzdGhyZXNoCmVxdWFscyAyLCBpdCB3aWxs IG5vdCBzZXQgaXQgdG8gMSwgYnV0IGxlYXZlIGl0IGF0IDIuCkhvd2V2ZXIsIHdpdGggUmFtaW4n cyBwcm9wb3NhbCBpdCB3aWxsIHNldCBpdCB0byAxLCBlZmZlY3RpdmVseSBhbGxvd2luZwphIHNl bmRpbmctcmF0ZSBvZiAxIHBhY2tldCBwZXIgUlRULgoKVGhlIHRleHQgcHJvYmFibHkgbmVlZHMg dG8gYmUgY2hhbmdlZCB0byByZWZsZWN0IHRoaXMuCgoKQ2hlZXJzLApDaHJpc3RvcGgKCjM6IMKg IkluIHRoZSBjYXNlIG9mIGEgc2luZ2xlIHBhdGggZmxvdywgd2UgdXNlIHRoZSBzYW1lIG1pbmlt dW0Kc3N0aHJlc2ggYXMgaW4gVENQIChpLmUuIDIgTVNTKS4iCsKgIMKgIC0+IEkgYW0gbm90IHZl cnkgc3VyZSBob3cgdGhlIG1pbmltdW0gc3N0aHJlc2ggYWZmZWN0cyBPTElBLiBJCmd1ZXNzIGl0 IHdpbGwgYmUgdXNlZCBvbmx5IGFmdGVyIGxvc3MuCkFzIHByZXZpb3VzbHkgbWVudGlvbmVkLCBJ IGd1ZXNzIHRoaXMgY29uZnVzaW9uIGNvbWVzIGZyb20gdGhlIGZhY3QKdGhhdCBzc3RocmVzaCBo YXMgYmVlbiB1c2VkIChpbnN0ZWFkIG9mIG1pbmltdW0gY29uZ2VzdGlvbiB3aW5kb3cpLgpMZXQg bWUga25vdyBpZiBJIGFtIHdyb25nLgpJZiBJIGFtIHJpZ2h0LCBJIHRoaW5rIGl0IGlzIGltcG9y dGFudCB0byBhZGFwdCB0aGUgZHJhZnQgcmVnYXJkaW5nCnRoaXMgaXNzdWUuCgpLaW5kIHJlZ2Fy ZHMsCgpOaWNvbGFzCgpUaGFua3MsCi0tCllvc2hpZnVtaQoKCk9uIE1vbiwgT2N0IDIxLCAyMDEz IGF0IDI6NDYgQU0sIFJhbWluIEtoYWxpbGkKPHJhbWluc3RlckBnbWFpbC5jb20+IHdyb3RlOgpE ZWFyIE5pY29sYXMsIFlvc2hpZnVtaSwKClRoYW5rcyBmb3IgeW91ciBjb21tZW50cyBhbmQgcG9p bnRzLiBXZSBoYXZlIGFwcGx5IHRoZW0gaW4gb3VyCmRyYWZ0IGFuZCB3aWxsIHN1Ym1pdCB0aGUg bmV3IHZlcnNpb24gb2Ygb3VyIGRyYWZ0IGJ5IHRoaXMKYWZ0ZXJub29uIChJIHdpbGwgc2VuZCBh IHN1Ym1pc3Npb24gbm90aWNlIHdoZW4gdGhlIG5ldyB2ZXJzaW9uIGlzCmF2YWlsYWJsZSkuCldp dGggcmVnYXJkcyB0byB0aGUgcXVlc3Rpb24gYWJvdXQgc3N0aHJlc2gsIGFzIE5pY29sYXMgc2Fp ZCwKdGhlIG1haW4gZ29hbCBpcyB0byB0byBhdm9pZCB0aGUgb3ZlcnVzZSBvZiBhIGNvbmdlc3Rl ZCBwYXRoCndoZXJlYXMgb3RoZXIgcGF0aHMgYXJlIGF2YWlsYWJsZS4KV2l0aCBDaHJpc3RvcGgg UGFhc2NoIGZyb20gVUNMb3V2YWluLCB3ZSBoYXZlIGRvbmUgYSBudW1iZXIgb2YKZXhwZXJpbWVu dHMgdG8gc3R1ZHkgdGhlIGVmZmVjdCBvZiBzZXR0aW5nIHRoZSBtaW5pbXVtIHNzdGhyZXNoIHRv CjEuIFdlIG9ic2VydmVkIHRoYXQgaXQgaW1wcm92ZXMgdGhlIGxvYWQgYmFsYW5jaW5nIGluIHRo ZSBuZXR3b3JrCmJ1dCB0aGUgZ2FpbiBpcyBub3QgdmVyeSBzaWduaWZpY2FudC4gTm90ZSB0aGF0 IG1pbmltdW0gc3N0aHJlc2gKZm9yIHNpbmdsZSBwYXRoIFRDUCB3b3VsZCBiZSBzdGlsbCAyIE1T UzsgaGVuY2UsIG91ciBtb2RpZmljYXRpb24Kd2lsbCBub3QgZWZmZWN0IHRoZSBzaW5nbGUgcGF0 aCBUQ1AgcGVyZm9ybWFuY2UuCkNoZWVycywKClJhbWluLgoKCgoKLS0tLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLS0tLQpTdWJqZWN0OiDCoCDCoCDCoCDCoFJlOiBbbXVsdGlwYXRodGNwXSBz b21lIGNvbW1lbnRzIG9uCmRyYWZ0LWtoYWxpbGktbXB0Y3AtY29uZ2VzdGlvbi1jb250cm9sLTAx CkRhdGU6IMKgIFRodSwgMjYgU2VwIDIwMTMgMDA6MzI6NDIgLTA3MDAKRnJvbTogwqAgWW9zaGlm dW1pIE5pc2hpZGEgPG5pc2hpZGFAc2ZjLndpZGUuYWQuanA+ClRvOiDCoCDCoCBOaWNvbGFzIEt1 aG4gPG5pY29sYXMua3VobkBpc2FlLmZyPgpDQzogwqAgwqAgbXVsdGlwYXRodGNwIDxtdWx0aXBh dGh0Y3BAaWV0Zi5vcmc+CgoKCkhpIE5pY29sYXMsCgpUaGFua3MgZm9yIHRoZSByZXNwb25zZS4K Ck9uIE1vbiwgU2VwIDIzLCAyMDEzIGF0IDEyOjAxIEFNLCBOaWNvbGFzIEt1aG4KPG5pY29sYXMu a3VobkBpc2FlLmZyCjxtYWlsdG86bmljb2xhcy5rdWhuQGlzYWUuZnI+PiB3cm90ZToKCsKgIMKg IMKgSGVsbG8sCgrCoCDCoCDCoExlIDIzLzA5LzIwMTMgMDg6MDAsIFlvc2hpZnVtaSBOaXNoaWRh IGEgw6ljcml0IDoKwqAgwqAgwqBIZWxsbywKwqAgwqAgwqBJJ3ZlIHJlYWQgZHJhZnQta2hhbGls aS1tcHRjcC1jb25nZXN0aW9uLWNvbnRyb2wtMDEgd2l0aCBncmVhdArCoCDCoCDCoGludGVyZXN0 cyBhbmQgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzLiBQbGVhc2UgbGV0IG1lCmtub3cgaWYg SQrCoCDCoCDCoG1pc3Mgc29tZXRoaW5nLgoKwqAgwqAgwqAxOiBJdCBzZWVtcyB0byBtZSB0aGF0 IGhvdyB0byBkZXRlcm1pbmUgY29sbGVjdGl2ZV9wYXRocyBhbmQKwqAgwqAgwqBtYXhfd19wYXRo cyBhcmUgYSBiaXQgYW1iaWd1b3VzLiBTaW5jZSB0aGV5IGFyZSAicGF0aHMiLCBpdApzZWVtcwrC oCDCoCDCoHRoYXQgdGhleSBhcmUgZXhwZWN0ZWQgdG8gYmUgbW9yZSB0aGFuIDEuCsKgIMKgIMKg SG93ZXZlciwgSSdtIG5vdCB2ZXJ5IHN1cmUgYWJvdXQgdGhlIGxvZ2ljIHRvIGNob29zZSB0aGVt LiBGb3IKwqAgwqAgwqBleGFtcGxlLCBpZiAzIHBhdGhzIGhhdmUKwqAgwqAgwqAxME1TUywgMjBN U1MsIDMwTVNTIGN3bmQgcmVzcGVjdGl2ZWx5LCBkbyB3ZSBjaG9vc2UgdGhlCjIwTVNTIHBhdGgK wqAgwqAgwqBhcyBvbmUgb2YgbWF4X3dfcGF0aHM/IE9yLCBob3cgYWJvdXQgMTBNU1MsIDI5TVNT LCAzME1TUyBjYXNlPwoKwqAgwqAgwqBNb3JlIGRldGFpbHMgY2FuIGJlIGZvdW5kIGluIFs1XSwg U2VjdGlvbiA0LjE6IEVxdWF0aW9ucyAoMykKYW5kICg0KQrCoCDCoCDCoHNob3VsZCBiZSBpbmNs dWRlZCBpbiB0aGUgZHJhZnQuCgoKT0suIFRoYW5rcyBmb3IgdGhlIGluZm8uCgrCoCDCoCDCoDI6 IERvIHdlIHJlYWxseSBuZWVkIHRvIHNldCB0aGUgc3N0aHJlc2ggdG8gMSBNU1Mgd2hlbgptdWx0 aXBsZQrCoCDCoCDCoHBhdGhzIGFyZSB1c2VkPyBSRkM2MzU2IGRvZXNuJ3QgaGF2ZSB0aGlzIGtp bmQgb2YgbG9naWMuIEknbQrCoCDCoCDCoHdvbmRlcmluZyB3aHkgdGhpcyBpcyByZXF1aXJlZC4g QWxzbywgaW4gY2FzZSBvZiBzaW5nbGUKcGF0aCwgdGhlCsKgIMKgIMKgZHJhZnQgcmVxdWlyZXMg dG8gc2V0IHRoZSBzc3RocmVzaCB0byAyIE1TUywgYnV0IEknbSBub3QKdmVyeSBzdXJlCsKgIMKg IMKgYWJvdXQgdGhlIHJhdGlvbmFsZSBiZWhpbmQgdGhpcy4KCsKgIMKgIMKgVGhpcyBtYXkgYmUg cmVxdWlyZWQgdG8gYXZvaWQgdGhlIG92ZXJ1c2Ugb2YgYSBjb25nZXN0ZWQgcGF0aArCoCDCoCDC oHdoZXJlYXMgb3RoZXIgcGF0aHMgYXJlIGF2YWlsYWJsZS4gSWYgdGhlcmUgYXJlIG1hbnkgcGF0 aHMsCnRoZXJlIGlzCsKgIMKgIMKgbm8gdXNlIGluIHNwb2lsaW5nIG1lZGlhIHJlc291cmNlcyB3 aXRoIHNzdGhyZXNoIHNldCB0byAyCk1TUy4gSQrCoCDCoCDCoGd1ZXNzIHRoaXMgcGFyYW1ldGVy IGlzIHNldCB0byAxIE1TUyB0byBwcm9wZXJseSBvbmx5CmFuYWx5emUgdGhlCsKgIMKgIMKgdHJh ZmZpYyBhcm91bmQuCgrCoCDCoCDCoFRoZSBhdXRob3JzIG1heSBoYXZlIG1vcmUgZXhwbGFuYXRp b25zIHRoYW4gSSBkby4KCgpJIHBlcnNvbmFsbHkgdGhpbmsgc2V0dGluZyBzbWFsbCBzc3RocmVz aCBpcyBub3QgdmVyeSBuZWNlc3NhcmlseSwKZXNwZWNpYWxseSBmb3Igc2luZ2xlIHBhdGggY2Fz ZS4KSWYgdGhpcyBpcyBhbiBpbXBvcnRhbnQgcG9pbnQgZm9yIHRoZSBsb2dpYywgSSB3b3VsZCBs aWtlIHRvIHNlZQpzb21lCnJhdGlvbmFsZSBpbiB0aGUgZHJhZnQuCkkgaG9wZSBhdXRob3JzIHdp bGwgYWRkcmVzcyB0aGlzIGluIG5ldyB2ZXJzaW9uLgoKVGhhbmtzLAotLQpZb3NoaWZ1bWkKCgoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbXVsdGlwYXRo dGNwIG1haWxpbmcgbGlzdAptdWx0aXBhdGh0Y3BAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tdWx0aXBhdGh0Y3AKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KbXVsdGlwYXRodGNwIG1haWxpbmcgbGlzdAptdWx0aXBh dGh0Y3BAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWx0 aXBhdGh0Y3AKCgo= ----_com.android.email_497684347424200 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5TdXJlLCBJIHdpbGwgYWRk IGEgZGlzY3Vzc2lvbiBwYXJ0IGFib3V0IHRoaXMgbW9kaWZpY2F0aW9uIGFuZCB3aWxsIHVkYXRl IHRoZSBuZXcgdmVyc2lvbi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlJlZ2FyZHMsPC9kaXY+ PGRpdj5SYW1pbi48L2Rpdj48ZGl2Pjxicj48L2Rpdj4gPGJyPjxicj48YnI+LS0tLS0tLS0gT3Jp Z2luYWwgbWVzc2FnZSAtLS0tLS0tLTxicj5Gcm9tOiBZb3NoaWZ1bWkgTmlzaGlkYSAmbHQ7bmlz aGlkYUBzZmMud2lkZS5hZC5qcCZndDsgPGJyPkRhdGU6ICA8YnI+VG86IFJhbWluIEtoYWxpbGkg Jmx0O3JhbWluQG5ldC50LWxhYnMudHUtYmVybGluLmRlJmd0OyA8YnI+Q2M6IENocmlzdG9waCBQ YWFzY2ggJmx0O2NocmlzdG9waC5wYWFzY2hAdWNsb3V2YWluLmJlJmd0OyxLVUhOIE5pY29sYXMg Jmx0O05pY29sYXMuS3VobkBpc2FlLmZyJmd0OyxtdWx0aXBhdGh0Y3AgJmx0O211bHRpcGF0aHRj cEBpZXRmLm9yZyZndDssWW9zaGlmdW1pIE5pc2hpZGEgJmx0O25pc2hpZGFAc2ZjLndpZGUuYWQu anAmZ3Q7IDxicj5TdWJqZWN0OiBSZTogW211bHRpcGF0aHRjcF0gc29tZSBjb21tZW50cyBvbiBk cmFmdC1raGFsaWxpLW1wdGNwLWNvbmdlc3Rpb24tY29udHJvbC0wMSA8YnI+IDxicj48YnI+PGRp diBkaXI9Imx0ciI+SGkgUmFtaW4sIENocmlzdG9waCwgTmljb2xhcyw8ZGl2Pjxicj48L2Rpdj48 ZGl2PlRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24uPGJyPjxkaXY+SSBqdXN0IHRob3VnaHQg T0xJQSB1c2VzIGxvdyBzc3RocmVzaCBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBjb25uZWN0aW9u IHdoZW4gSSByZWFkIHRoZSB0ZXh0LCBidXQgbm93IEkgdGhpbmsgSSB1bmRlcnN0YW5kLjwvZGl2 Pgo8ZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj5JIHRoaW5rIEkgc3RpbGwgbmVlZCB0byB1 bmRlcnN0YW5kIGhvdyB1c2luZyAxIE1TUyBmb3IgbWluaW11bSBzc3RocmVzaCBjYW4gYWZmZWN0 IHRoZSBwZXJmb3JtYW5jZS48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+SSdtIGhvcGlu ZyB5b3Ugd2lsbCBhZGQgc29tZSBkaXNjdXNzaW9ucyBvbiB0aGlzIHBvaW50IGluIHRoZSBuZXcg dmVyc2lvbi48L2Rpdj4KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48L2Rpdj48ZGl2IGNs YXNzPSJnbWFpbF9leHRyYSI+VGhhbmtzLDwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4t LTwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj5Zb3NoaWZ1bWkmbmJzcDs8YnI+PGJyPjxk aXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBXZWQsIE9jdCAyMywgMjAxMyBhdCA3OjAwIEFNLCBS YW1pbiBLaGFsaWxpIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnJhbWluQG5l dC50LWxhYnMudHUtYmVybGluLmRlIiB0YXJnZXQ9Il9ibGFuayI+cmFtaW5AbmV0LnQtbGFicy50 dS1iZXJsaW4uZGU8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPgo8YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2Nj YyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij5IaSBZb3NoaWZ1bWksPGJyPgo8YnI+CkFzIE5pY29s YXMgYW5kIENocmlzdG9waCBzYWlkLCB0aGUgbW90aXZhdGlvbiBiZWhpbmQgdGhpcyBtb2RpZmlj YXRpb24gaXMgdG8gYmUgbGVzcyBhZ2dyZXNzaXZlIG92ZXIgYSB2ZXJ5IGxvc3N5IHBhdGguIFRD UCBuZXctcmVubyB1c2VzIHNzdGhyZXNoIHRvIGRlY2lkZSBpZiB0aGUgdXNlciBpcyBpbiBzbG93 IHN0YXJ0IG9yIGNvbmdlc3Rpb24gYXZvaWRhbmNlIHBoYXNlIChpZiBjd25kID0mbHQ7IHNzdGhy ZXNoIHdlIGFyZSBpbiBzbG93IHN0YXJ0LCBvLncuIGNvbmdlc3Rpb24gYXZvaWRhbmNlKS4gTm90 ZSB0aGF0IGN3bmQgaW5jcmVhc2VzIG11Y2ggZmFzdGVyIGR1cmluZyB0aGUgc2xvdyBzdGFydCBw aGFzZSB0aGFuIGNvbmdlc3Rpb24gYXZvaWRhbmNlLjxicj4KCjxicj4KVG8gaGF2ZSBhIGdvb2Qg bG9hZCBiYWxhbmNpbmcgaW4gdGhlIG5ldHdvcmssIHdlIHNob3VsZCBub3QgdXNlIHBhdGhzIHRo YXQgaGF2ZSB2ZXJ5IGJhZCBwZXJmb3JtYW5jZS4gSWYgd2UgdXNlIG1pbmltdW0gc3N0aHJlc2gg b2YgMiBNU1MsIGN3bmQgd291bGQgYmUgYWxtb3N0IGFsd2F5cyBncmVhdGVyIHRoYW4gM01TUyBv biBhIHBhdGggZXZlbiBpZiB0aGUgcGF0aCBpcyB2ZXJ5IGxvc3N5IChiZWNhdXNlIHNsb3cgc3Rh cnQgaXMgbW9yZSBhZ2dyZXNzaXZlIHRoYW4gY29uZ2VzdGlvbiBhdm9pZGFuY2UpLiBUaGlzIHJl c3VsdHMgdG8gYSBtaW5pbXVtIHRyYWZmaWMgcmF0ZSBvZiAzTVNTL1JUVCBvdmVyIGEgcGF0aCB3 aGljaCBpcyB2ZXJ5IGhpZ2guPGJyPgoKPGJyPgpCeSBvdXIgbW9kaWZpY2F0aW9uLCB3ZSBhbGxv dyB0aGUgbWluaW11bSB0cmFmZmljIHJhdGUgb3ZlciBhIHBhdGggYmUgYXMgc21hbGwgYXMgMU1T Uy9SVFQuIE5vdGUgdGhhdCB3ZSBkbyBub3QgY2hhbmdlIHRoZSBtaW5pbXVtIHZhbHVlIG9mIGN3 bmQgYW5kIHNpbWlsYXJseSB0byBUQ1AgbmV3LXJlbm8gaXQgaXMgc2V0IHRvIDFNU1MuIEFsc28s IHRoaXMgbW9kaWZpY2F0aW9uIHdpbGwgbm90IGFmZmVjdCBnb29kIHBhdGhzIChhcyBmb3IgdGhl c2UgcGF0aHMsIHRoZSBwcm9iYWJpbGl0eSB0aGF0IHNzdGhyZXNoIGJlY29tZSAxTVNTIGlzIHZl cnkgc21hbGwpLiBBbHNvLCB3ZSBhcHBseSB0aGlzIG1vZGlmaWNhdGlvbiBvbmx5IGlmIG1vcmUg dGhhbiBvbmUgcGF0aCBpcyBhdmFpbGFibGUgdG8gdGhlIHVzZXIsIGhlbmNlLCBpdCBkb2VzIG5v dCBhZmZlY3QgdGhlIHBlcmZvcm1hbmNlIG9mIHNpbmdsZSBwYXRoIGNvbm5lY3Rpb25zLjxicj4K Cjxicj4KSSB3b3VsZCBhZGQgc29tZSBkaXNjdXNzaW9uIGluIHRoZSBkcmFmdCBhYm91dCB3aHkg YW5kIGhvdyB0aGlzIG1vZGlmaWNhdGlvbiBpcyBhcHBsaWVkLiBJIGFtIHdvbmRlcmluZyBpZiBJ IGNhbiB1cGxvYWQgdGhlIG5ldyB2ZXJzaW9uIGFmdGVyIHRoZSBtb2RpZmljYXRpb24/PGJyPgo8 YnI+CkJlc3QgcmVnYXJkcyw8YnI+ClJhbWluLjxicj4KPGJyPgo8YnI+Cjxicj4KQW0gMjMuMTAu MjAxMyAxMDoyOSwgc2NocmllYiBDaHJpc3RvcGggUGFhc2NoOjxkaXYgY2xhc3M9IkhPRW5aYiI+ PGRpdiBjbGFzcz0iaDUiPjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1s ZWZ0OjFleCI+CkhlbGxvLDxicj4KPGJyPgpPbiAyMy8xMC8xMyAtIDEwOjA5OjMxLCBLVUhOIE5p Y29sYXMgd3JvdGU6PGJyPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJt YXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6 MWV4Ij4KTGUgMjMvMTAvMjAxMyAwNjo1MywgWW9zaGlmdW1pIE5pc2hpZGEgYSDDqWNyaXQgOjxi cj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+ClRoYW5rcyBm b3IgdGhlIHJlcGx5LiBCdXQsIEkgdGhpbmsgSSBhbSBzdGlsbCBhIGJpdCBjb25mdXNlZC48YnI+ Ck1heWJlIEkgb3Zlcmxvb2sgc29tZXRoaW5nLi4uPGJyPgpJIHRoaW5rIEkgd2lsbCBuZWVkIHRv IHRoaW5rIGFib3V0IFNlY3Rpb24gMyBtb3JlIGNhcmVmdWxseS4gSXQ8YnI+CndvdWxkIGJlIGdy ZWF0IGlmIHlvdSBjYW4gcG9pbnQgb3V0IHdoYXQgSSdtIG1pc3NpbmcuPGJyPgo8YnI+CjE6ICJU aGUgYWxnb3JpdGhtIG9ubHkgYXBwbGllcyB0byB0aGUgaW5jcmVhc2UgcGFydCBvZiB0aGU8YnI+ CmNvbmdlc3Rpb24gYXZvaWRhbmNlIHBoYXNlLiI8YnI+CiZuYnNwOyAmbmJzcDsgJm5ic3A7LSZn dDsgSXQgc2VlbXMgdG8gbWUgdGhhdCBPTElBIGRvZXMgbm90aGluZyBkdXJpbmcgc2xvdyBzdGFy dDxicj4KcGhhc2UsIHdoaWNoIGlzIGZpbmUgZm9yIG1lLjxicj4KPGJyPgo8L2Jsb2NrcXVvdGU+ ClRoZSBhbGdvcml0aG0gYmVoaW5kIE9MSUEgY29uZ2VzdGlvbiB3aW5kb3dzIHVwZGF0ZXMgbXVz dCBiZTxicj4KaW50cm9kdWNlZCBpbiBjb25nZXN0aW9uIGF2b2lkYW5jZSBwaGFzZS4gQW5kIHRo ZSBzbG93IHN0YXJ0IHBoYXNlPGJyPgpzaG91bGQgYmUgdGhlIHNhbWUgYXMgVENQLiBJIGFncmVl IHdpdGggeW91IG9uIHRoYXQgcG9pbnQuPGJyPgo8YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNv bGlkO3BhZGRpbmctbGVmdDoxZXgiPgoyOiAiV2UgYWxzbyB1c2UgYSBzaW1pbGFyIHNsb3cgc3Rh cnQgYWxnb3JpdGhtIGFzIGluIFRDUCwgd2l0aCB0aGU8YnI+Cm1vZGlmaWNhdGlvbiB0aGF0IHdl IHNldCB0aGUgc3N0aHJlc2ggKHNsb3cgc3RhcnQgdGhyZXNob2xkKSB0byBiZTxicj4KMSBNU1Mg aWYgbXVsdGlwbGUgcGF0aHMgYXJlIGVzdGFibGlzaGVkLiI8YnI+CiZuYnNwOyAmbmJzcDsgJm5i c3A7LSZndDsgSXQgc2VlbXMgdG8gbWUgdGhhdCBPTElBIHN1cHBvcnRzIHNsb3ctc3RhcnQgbGlr ZTxicj4KYWxnb3JpdGhtLiBCdXQsIGlmIHlvdSBzZXQgc3N0aHJlc2ggdG8gYmUgMSBNU1MsIEkn bSBub3Qgc3VyZSBob3c8YnI+CnlvdSBjYW4gYWN0aXZhdGUgaXQuIEFsc28sIHRoaXMgc291bmRz IGEgYml0IGNvbnRyYWRpY3RvcnkgdG8gMTogLjxicj4KPGJyPgo8L2Jsb2NrcXVvdGU+CkhlcmUg Y29tZXMgdGhlIGNvbmZ1c2lvbi4gU2V0dGluZyBzc3RocmVzaCB0byBiZSAxIE1TUyBtZWFucyB0 aGF0PGJyPgp0aGVyZSBpcyBubyBzbG93IHN0YXJ0IHBoYXNlOiB0aGUgY29uZ2VzdGlvbiB3aW5k b3cgaXMgYWx3YXlzPGJyPgpncmVhdGVyIHRoYW4gMU1TUyE8YnI+CkkgZ3Vlc3MgdGhlcmUgaXMg YSBtaXN0YWtlIGluIHRoZSBjdXJyZW50IGRyYWZ0IGFuZCBJIHByb3Bvc2UgdGhlPGJyPgpmb2xs b3dpbmcgY2hhbmdlczo8YnI+CjEtIHByZWNpc2UgdGhhdCwgYXMgZm9yIGNvbW1vbiBUQ1AsIHRo ZSBzc3RocmVzaCBpcyBpbml0aWFsaXplZCB0bzxicj4KImluZmluaXR5Ijs8YnI+CjItIHJlcGxh Y2Ugc3N0aHJlc2ggaG9sZCBpbiB0aGlzIHNlY3Rpb24gYnkgImluaXRpYWwgY29uZ2VzdGlvbjxi cj4Kd2luZG93IiBvciAibWluaW11bSBjb25nZXN0aW9uIHdpbmRvdyIuPGJyPgo8L2Jsb2NrcXVv dGU+CnRoZSBzZXR0aW5nIG9mIHNzdGhyZXNoIHRvIDEgaXMgZG9uZSwgd2hlbiBzdWJzZXF1ZW50 IGxvc3NlcyBtYWtlIHRoZTxicj4Kc3N0aHJlc2ggY29tZSBkb3duIHRvIDIuIEluIHJlZ3VsYXIg VENQLCBpZiBhIGxvc3MgaGFwcGVucyBhbmQgc3N0aHJlc2g8YnI+CmVxdWFscyAyLCBpdCB3aWxs IG5vdCBzZXQgaXQgdG8gMSwgYnV0IGxlYXZlIGl0IGF0IDIuPGJyPgpIb3dldmVyLCB3aXRoIFJh bWluJ3MgcHJvcG9zYWwgaXQgd2lsbCBzZXQgaXQgdG8gMSwgZWZmZWN0aXZlbHkgYWxsb3dpbmc8 YnI+CmEgc2VuZGluZy1yYXRlIG9mIDEgcGFja2V0IHBlciBSVFQuPGJyPgo8YnI+ClRoZSB0ZXh0 IHByb2JhYmx5IG5lZWRzIHRvIGJlIGNoYW5nZWQgdG8gcmVmbGVjdCB0aGlzLjxicj4KPGJyPgo8 YnI+CkNoZWVycyw8YnI+CkNocmlzdG9waDxicj4KPGJyPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5n LWxlZnQ6MWV4Ij4KMzogJm5ic3A7IkluIHRoZSBjYXNlIG9mIGEgc2luZ2xlIHBhdGggZmxvdywg d2UgdXNlIHRoZSBzYW1lIG1pbmltdW08YnI+CnNzdGhyZXNoIGFzIGluIFRDUCAoaS5lLiAyIE1T UykuIjxicj4KJm5ic3A7ICZuYnNwOyAtJmd0OyBJIGFtIG5vdCB2ZXJ5IHN1cmUgaG93IHRoZSBt aW5pbXVtIHNzdGhyZXNoIGFmZmVjdHMgT0xJQS4gSTxicj4KZ3Vlc3MgaXQgd2lsbCBiZSB1c2Vk IG9ubHkgYWZ0ZXIgbG9zcy48YnI+CjwvYmxvY2txdW90ZT4KQXMgcHJldmlvdXNseSBtZW50aW9u ZWQsIEkgZ3Vlc3MgdGhpcyBjb25mdXNpb24gY29tZXMgZnJvbSB0aGUgZmFjdDxicj4KdGhhdCBz c3RocmVzaCBoYXMgYmVlbiB1c2VkIChpbnN0ZWFkIG9mIG1pbmltdW0gY29uZ2VzdGlvbiB3aW5k b3cpLjxicj4KTGV0IG1lIGtub3cgaWYgSSBhbSB3cm9uZy48YnI+CklmIEkgYW0gcmlnaHQsIEkg dGhpbmsgaXQgaXMgaW1wb3J0YW50IHRvIGFkYXB0IHRoZSBkcmFmdCByZWdhcmRpbmc8YnI+CnRo aXMgaXNzdWUuPGJyPgo8YnI+CktpbmQgcmVnYXJkcyw8YnI+Cjxicj4KTmljb2xhczxicj4KPGJy Pgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhl eDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KVGhhbmtzLDxi cj4KLS08YnI+Cllvc2hpZnVtaTxicj4KPGJyPgo8YnI+Ck9uIE1vbiwgT2N0IDIxLCAyMDEzIGF0 IDI6NDYgQU0sIFJhbWluIEtoYWxpbGk8YnI+CiZsdDs8YSBocmVmPSJtYWlsdG86cmFtaW5zdGVy QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJhbWluc3RlckBnbWFpbC5jb208L2E+Jmd0OyB3 cm90ZTo8YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjow IDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPgpE ZWFyIE5pY29sYXMsIFlvc2hpZnVtaSw8YnI+Cjxicj4KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRz IGFuZCBwb2ludHMuIFdlIGhhdmUgYXBwbHkgdGhlbSBpbiBvdXI8YnI+CjwvYmxvY2txdW90ZT4K ZHJhZnQgYW5kIHdpbGwgc3VibWl0IHRoZSBuZXcgdmVyc2lvbiBvZiBvdXIgZHJhZnQgYnkgdGhp czxicj4KYWZ0ZXJub29uIChJIHdpbGwgc2VuZCBhIHN1Ym1pc3Npb24gbm90aWNlIHdoZW4gdGhl IG5ldyB2ZXJzaW9uIGlzPGJyPgphdmFpbGFibGUpLjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mg c29saWQ7cGFkZGluZy1sZWZ0OjFleCI+CldpdGggcmVnYXJkcyB0byB0aGUgcXVlc3Rpb24gYWJv dXQgc3N0aHJlc2gsIGFzIE5pY29sYXMgc2FpZCw8YnI+CjwvYmxvY2txdW90ZT4KdGhlIG1haW4g Z29hbCBpcyB0byB0byBhdm9pZCB0aGUgb3ZlcnVzZSBvZiBhIGNvbmdlc3RlZCBwYXRoPGJyPgp3 aGVyZWFzIG90aGVyIHBhdGhzIGFyZSBhdmFpbGFibGUuPGJyPgo8YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2Nj YyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KV2l0aCBDaHJpc3RvcGggUGFhc2NoIGZyb20gVUNM b3V2YWluLCB3ZSBoYXZlIGRvbmUgYSBudW1iZXIgb2Y8YnI+CjwvYmxvY2txdW90ZT4KZXhwZXJp bWVudHMgdG8gc3R1ZHkgdGhlIGVmZmVjdCBvZiBzZXR0aW5nIHRoZSBtaW5pbXVtIHNzdGhyZXNo IHRvPGJyPgoxLiBXZSBvYnNlcnZlZCB0aGF0IGl0IGltcHJvdmVzIHRoZSBsb2FkIGJhbGFuY2lu ZyBpbiB0aGUgbmV0d29yazxicj4KYnV0IHRoZSBnYWluIGlzIG5vdCB2ZXJ5IHNpZ25pZmljYW50 LiBOb3RlIHRoYXQgbWluaW11bSBzc3RocmVzaDxicj4KZm9yIHNpbmdsZSBwYXRoIFRDUCB3b3Vs ZCBiZSBzdGlsbCAyIE1TUzsgaGVuY2UsIG91ciBtb2RpZmljYXRpb248YnI+CndpbGwgbm90IGVm ZmVjdCB0aGUgc2luZ2xlIHBhdGggVENQIHBlcmZvcm1hbmNlLjxicj4KPGJsb2NrcXVvdGUgY2xh c3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4 ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+CkNoZWVycyw8YnI+Cjxicj4KUmFtaW4uPGJy Pgo8YnI+Cjxicj4KPGJyPgo8YnI+Ci0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS08 YnI+ClN1YmplY3Q6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1JlOiBbbXVsdGlwYXRodGNw XSBzb21lIGNvbW1lbnRzIG9uPGJyPgpkcmFmdC1raGFsaWxpLW1wdGNwLTx1PjwvdT5jb25nZXN0 aW9uLWNvbnRyb2wtMDE8YnI+CkRhdGU6ICZuYnNwOyBUaHUsIDI2IFNlcCAyMDEzIDAwOjMyOjQy IC0wNzAwPGJyPgpGcm9tOiAmbmJzcDsgWW9zaGlmdW1pIE5pc2hpZGEgJmx0OzxhIGhyZWY9Im1h aWx0bzpuaXNoaWRhQHNmYy53aWRlLmFkLmpwIiB0YXJnZXQ9Il9ibGFuayI+bmlzaGlkYUBzZmMu d2lkZS5hZC5qcDwvYT4mZ3Q7PGJyPgpUbzogJm5ic3A7ICZuYnNwOyBOaWNvbGFzIEt1aG4gJmx0 OzxhIGhyZWY9Im1haWx0bzpuaWNvbGFzLmt1aG5AaXNhZS5mciIgdGFyZ2V0PSJfYmxhbmsiPm5p Y29sYXMua3VobkBpc2FlLmZyPC9hPiZndDs8YnI+CkNDOiAmbmJzcDsgJm5ic3A7IG11bHRpcGF0 aHRjcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm11bHRpcGF0aHRjcEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPm11bHRpcGF0aHRjcEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPgo8YnI+Cjxicj4KPGJyPgpI aSBOaWNvbGFzLDxicj4KPGJyPgpUaGFua3MgZm9yIHRoZSByZXNwb25zZS48YnI+Cjxicj4KT24g TW9uLCBTZXAgMjMsIDIwMTMgYXQgMTI6MDEgQU0sIE5pY29sYXMgS3Vobjxicj4KPC9ibG9ja3F1 b3RlPgombHQ7PGEgaHJlZj0ibWFpbHRvOm5pY29sYXMua3VobkBpc2FlLmZyIiB0YXJnZXQ9Il9i bGFuayI+bmljb2xhcy5rdWhuQGlzYWUuZnI8L2E+PGJyPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bmljb2xh cy5rdWhuQGlzYWUuZnIiIHRhcmdldD0iX2JsYW5rIj5uaWNvbGFzLmt1aG5AaXNhZS5mcjwvYT4m Z3Q7Jmd0OyB3cm90ZTo8YnI+Cjxicj4KJm5ic3A7ICZuYnNwOyAmbmJzcDtIZWxsbyw8YnI+Cjxi cj4KJm5ic3A7ICZuYnNwOyAmbmJzcDtMZSAyMy8wOS8yMDEzIDA4OjAwLCBZb3NoaWZ1bWkgTmlz aGlkYSBhIMOpY3JpdCA6PGJyPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxl ZnQ6MWV4Ij4KJm5ic3A7ICZuYnNwOyAmbmJzcDtIZWxsbyw8YnI+CiZuYnNwOyAmbmJzcDsgJm5i c3A7SSd2ZSByZWFkIGRyYWZ0LWtoYWxpbGktbXB0Y3AtPHU+PC91PmNvbmdlc3Rpb24tY29udHJv bC0wMSB3aXRoIGdyZWF0PGJyPgombmJzcDsgJm5ic3A7ICZuYnNwO2ludGVyZXN0cyBhbmQgaGF2 ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzLiBQbGVhc2UgbGV0IG1lPGJyPgo8L2Jsb2NrcXVvdGU+ PC9ibG9ja3F1b3RlPgprbm93IGlmIEk8YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3Bh ZGRpbmctbGVmdDoxZXgiPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1h cmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDox ZXgiPgombmJzcDsgJm5ic3A7ICZuYnNwO21pc3Mgc29tZXRoaW5nLjxicj4KPGJyPgombmJzcDsg Jm5ic3A7ICZuYnNwOzE6IEl0IHNlZW1zIHRvIG1lIHRoYXQgaG93IHRvIGRldGVybWluZSBjb2xs ZWN0aXZlX3BhdGhzIGFuZDxicj4KJm5ic3A7ICZuYnNwOyAmbmJzcDttYXhfd19wYXRocyBhcmUg YSBiaXQgYW1iaWd1b3VzLiBTaW5jZSB0aGV5IGFyZSAicGF0aHMiLCBpdDxicj4KPC9ibG9ja3F1 b3RlPjwvYmxvY2txdW90ZT4Kc2VlbXM8YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3Bh ZGRpbmctbGVmdDoxZXgiPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1h cmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDox ZXgiPgombmJzcDsgJm5ic3A7ICZuYnNwO3RoYXQgdGhleSBhcmUgZXhwZWN0ZWQgdG8gYmUgbW9y ZSB0aGFuIDEuPGJyPgombmJzcDsgJm5ic3A7ICZuYnNwO0hvd2V2ZXIsIEknbSBub3QgdmVyeSBz dXJlIGFib3V0IHRoZSBsb2dpYyB0byBjaG9vc2UgdGhlbS4gRm9yPGJyPgombmJzcDsgJm5ic3A7 ICZuYnNwO2V4YW1wbGUsIGlmIDMgcGF0aHMgaGF2ZTxicj4KJm5ic3A7ICZuYnNwOyAmbmJzcDsx ME1TUywgMjBNU1MsIDMwTVNTIGN3bmQgcmVzcGVjdGl2ZWx5LCBkbyB3ZSBjaG9vc2UgdGhlPGJy Pgo8L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPgoyME1TUyBwYXRoPGJyPgo8YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDox cHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xp ZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KJm5ic3A7ICZuYnNwOyAmbmJzcDthcyBvbmUgb2YgbWF4X3df cGF0aHM/IE9yLCBob3cgYWJvdXQgMTBNU1MsIDI5TVNTLCAzME1TUyBjYXNlPzxicj4KPGJyPgo8 L2Jsb2NrcXVvdGU+CiZuYnNwOyAmbmJzcDsgJm5ic3A7TW9yZSBkZXRhaWxzIGNhbiBiZSBmb3Vu ZCBpbiBbNV0sIFNlY3Rpb24gNC4xOiBFcXVhdGlvbnMgKDMpPGJyPgo8L2Jsb2NrcXVvdGU+CmFu ZCAoNCk8YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjow IDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPgom bmJzcDsgJm5ic3A7ICZuYnNwO3Nob3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUgZHJhZnQuPGJyPgo8 YnI+Cjxicj4KT0suIFRoYW5rcyBmb3IgdGhlIGluZm8uPGJyPgo8YnI+CjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPgombmJzcDsgJm5ic3A7ICZuYnNwOzI6IERv IHdlIHJlYWxseSBuZWVkIHRvIHNldCB0aGUgc3N0aHJlc2ggdG8gMSBNU1Mgd2hlbjxicj4KPC9i bG9ja3F1b3RlPjwvYmxvY2txdW90ZT4KbXVsdGlwbGU8YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2Nj IHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg c3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRp bmctbGVmdDoxZXgiPgombmJzcDsgJm5ic3A7ICZuYnNwO3BhdGhzIGFyZSB1c2VkPyBSRkM2MzU2 IGRvZXNuJ3QgaGF2ZSB0aGlzIGtpbmQgb2YgbG9naWMuIEknbTxicj4KJm5ic3A7ICZuYnNwOyAm bmJzcDt3b25kZXJpbmcgd2h5IHRoaXMgaXMgcmVxdWlyZWQuIEFsc28sIGluIGNhc2Ugb2Ygc2lu Z2xlPGJyPgo8L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPgpwYXRoLCB0aGU8YnI+CjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1s ZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2Nj IHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPgombmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0IHJlcXVp cmVzIHRvIHNldCB0aGUgc3N0aHJlc2ggdG8gMiBNU1MsIGJ1dCBJJ20gbm90PGJyPgo8L2Jsb2Nr cXVvdGU+PC9ibG9ja3F1b3RlPgp2ZXJ5IHN1cmU8YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNv bGlkO3BhZGRpbmctbGVmdDoxZXgiPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmct bGVmdDoxZXgiPgombmJzcDsgJm5ic3A7ICZuYnNwO2Fib3V0IHRoZSByYXRpb25hbGUgYmVoaW5k IHRoaXMuPGJyPgo8YnI+CjwvYmxvY2txdW90ZT4KJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGlzIG1h eSBiZSByZXF1aXJlZCB0byBhdm9pZCB0aGUgb3ZlcnVzZSBvZiBhIGNvbmdlc3RlZCBwYXRoPGJy PgombmJzcDsgJm5ic3A7ICZuYnNwO3doZXJlYXMgb3RoZXIgcGF0aHMgYXJlIGF2YWlsYWJsZS4g SWYgdGhlcmUgYXJlIG1hbnkgcGF0aHMsPGJyPgo8L2Jsb2NrcXVvdGU+CnRoZXJlIGlzPGJyPgo8 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDti b3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KJm5ic3A7ICZuYnNw OyAmbmJzcDtubyB1c2UgaW4gc3BvaWxpbmcgbWVkaWEgcmVzb3VyY2VzIHdpdGggc3N0aHJlc2gg c2V0IHRvIDI8YnI+CjwvYmxvY2txdW90ZT4KTVNTLiBJPGJyPgo8YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2Nj YyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KJm5ic3A7ICZuYnNwOyAmbmJzcDtndWVzcyB0aGlz IHBhcmFtZXRlciBpcyBzZXQgdG8gMSBNU1MgdG8gcHJvcGVybHkgb25seTxicj4KPC9ibG9ja3F1 b3RlPgphbmFseXplIHRoZTxicj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1s ZWZ0OjFleCI+CiZuYnNwOyAmbmJzcDsgJm5ic3A7dHJhZmZpYyBhcm91bmQuPGJyPgo8YnI+CiZu YnNwOyAmbmJzcDsgJm5ic3A7VGhlIGF1dGhvcnMgbWF5IGhhdmUgbW9yZSBleHBsYW5hdGlvbnMg dGhhbiBJIGRvLjxicj4KPGJyPgo8YnI+CkkgcGVyc29uYWxseSB0aGluayBzZXR0aW5nIHNtYWxs IHNzdGhyZXNoIGlzIG5vdCB2ZXJ5IG5lY2Vzc2FyaWx5LDxicj4KZXNwZWNpYWxseSBmb3Igc2lu Z2xlIHBhdGggY2FzZS48YnI+CklmIHRoaXMgaXMgYW4gaW1wb3J0YW50IHBvaW50IGZvciB0aGUg bG9naWMsIEkgd291bGQgbGlrZSB0byBzZWU8YnI+CjwvYmxvY2txdW90ZT4Kc29tZTxicj4KPGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9y ZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+CnJhdGlvbmFsZSBpbiB0 aGUgZHJhZnQuPGJyPgpJIGhvcGUgYXV0aG9ycyB3aWxsIGFkZHJlc3MgdGhpcyBpbiBuZXcgdmVy c2lvbi48YnI+Cjxicj4KVGhhbmtzLDxicj4KLS08YnI+Cllvc2hpZnVtaTxicj4KPGJyPgo8YnI+ Cjxicj4KPC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT4KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPHU+PC91Pl9fX19fX19fX19fX19fX19fPGJyPgptdWx0aXBhdGh0Y3AgbWFpbGluZyBs aXN0PGJyPgo8YSBocmVmPSJtYWlsdG86bXVsdGlwYXRodGNwQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bXVsdGlwYXRodGNwQGlldGYub3JnPC9hPjxicj4KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWx0aXBhdGh0Y3AiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx1PjwvdT5saXN0aW5mby9tdWx0aXBhdGh0Y3A8 L2E+PGJyPgo8L2Jsb2NrcXVvdGU+Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzx1Pjwv dT5fX19fX19fX19fX19fX19fXzxicj4KbXVsdGlwYXRodGNwIG1haWxpbmcgbGlzdDxicj4KPGEg aHJlZj0ibWFpbHRvOm11bHRpcGF0aHRjcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm11bHRp cGF0aHRjcEBpZXRmLm9yZzwvYT48YnI+CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXVsdGlwYXRodGNwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi88dT48L3U+bGlzdGluZm8vbXVsdGlwYXRodGNwPC9hPjxicj4KPC9i bG9ja3F1b3RlPgo8YnI+CjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+ PC9kaXY+PC9kaXY+PC9kaXY+CjwvYm9keT4= ----_com.android.email_497684347424200-- From rpaulo@apple.com Mon Oct 28 16:47:58 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 C0C2D21E80B7 for ; Mon, 28 Oct 2013 16:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPko2-66xYaH for ; Mon, 28 Oct 2013 16:47:52 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADF111E81D4 for ; Mon, 28 Oct 2013 16:47:10 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MVE00GCRKNVST92@mail-out.apple.com> for multipathtcp@ietf.org; Mon, 28 Oct 2013 16:46:14 -0700 (PDT) X-AuditID: 11807153-b7f246d000005e2f-4a-526ef74660ec Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 16.30.24111.647FE625; Mon, 28 Oct 2013 16:46:14 -0700 (PDT) Received: from rui-macbook-pro.apple.com ([17.193.13.39]) by sesame.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MVE002FDKP16B80@sesame.apple.com> for multipathtcp@ietf.org; Mon, 28 Oct 2013 16:46:13 -0700 (PDT) From: Rui Paulo In-reply-to: Date: Mon, 28 Oct 2013 16:46:13 -0700 Message-id: <4303ADEB-89E3-4AAB-99B8-F22BE1C95E55@apple.com> References: <52665129.8030509@net.t-labs.tu-berlin.de> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.1816) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDcoOv2PS/I4PYaXovPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoEro2fKB8aCr0wVMxfPZmxgXMDUxcjBISFgItGxwq6LkRPIFJO4 cG89WxcjF4eQQB+TxPyfCxghnCVMEhPfvGUBqWIW0JHo/f6NGcTmFdCTOHrmNROILSwQLPF8 fS8riM0moCTxrO8EO4jNCRS//nUNG4jNIqAqsWXSSzaIORoS1x82Q9naEk/eXWCFmGkj8a71 JyOILSRQKzFr8m2w+SJAuz58/8gEcamsxMS/JxgnMArMQnLSLCQnzUIydgEj8ypGgaLUnMRK Y73EgoKcVL3k/NxNjODAKwzewfhnmdUhRgEORiUe3g1rc4OEWBPLiitzDzFKcDArifDu35wX JMSbklhZlVqUH19UmpNafIhRmoNFSZx3YXd2kJBAemJJanZqakFqEUyWiYNTqoGxzKT1c/0u 21kbEl1nul5i+Dz9xZldORcblCyuiHA9eSyZz7b8wheP76nTrQW8v3/73aTM1Ni1do7Lq4/W wZvC1uxzefXSuHBqyo4/bec2JJ37fPKVkVyjiVsA/4YlwkofH7vPTv7TvszyX6lsDNsznQlO 5bsiatZ8Zji99IAr2/TLedeyHh2ZrMRSnJFoqMVcVJwIAOOGvjc4AgAA Cc: multipathtcp Subject: Re: [multipathtcp] new version of draft-khalili-mptcp-congestion-control X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 23:47:58 -0000 On 22 Oct 2013, at 10:50, Yoshifumi Nishida wrote: > I think we will need to re-charter if we want to proceed this. Please let us know if you have comments on this. Hmm, really? There is already a (apparently broken) MPTCP congestion control RFC. Why do we need to re-charter to improve on it? Just curious. -- Rui Paulo From nishida@sfc.wide.ad.jp Mon Oct 28 19:11:02 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 3CBA011E81CB for ; Mon, 28 Oct 2013 19:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.818 X-Spam-Level: X-Spam-Status: No, score=-101.818 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRVav0s8oiVo for ; Mon, 28 Oct 2013 19:11:00 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 1C40B21F9FA4 for ; Mon, 28 Oct 2013 19:10:58 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id DC09B2780A6 for ; Tue, 29 Oct 2013 11:10:55 +0900 (JST) Received: by mail-la0-f43.google.com with SMTP id el20so5938858lab.16 for ; Mon, 28 Oct 2013 19:10:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a9Tab1c30g7J+Q42GqAzj+7yR1RVSAfjLtv68s/cX0o=; b=bFYkkn5Bfd0mrCmvSD/LnOKld/bNFO0V4v8SziQxuovYMMRRGRgEOzrH+itOUPJEgz MlB0IqGB7k9dPMuNShqG1tom3zhntAw4gUsX6cAWD9ynhJVZWALcjrkL+7H+vSIiQ85M NT/F5W1K5SU3SAg/8BcKeQmFhhDXbpC0s/g2cPFKweyU4CovcxBeaIxnUHThCty2lfVI 9BWISUNHVUxiV2J2jLBnxs4QT5MHmY19koUjClOD78YlwwJhIopF922A2agQdIjtWu8n +bDr0skspXdmGKjqpEb/Epv02i/qbpPDLK6Sa25WBtB7xXH9gHc0ntZYJe8WNhPjjmLp Z7Gg== MIME-Version: 1.0 X-Received: by 10.152.120.228 with SMTP id lf4mr147742lab.44.1383012653361; Mon, 28 Oct 2013 19:10:53 -0700 (PDT) Received: by 10.114.99.99 with HTTP; Mon, 28 Oct 2013 19:10:53 -0700 (PDT) In-Reply-To: <4303ADEB-89E3-4AAB-99B8-F22BE1C95E55@apple.com> References: <52665129.8030509@net.t-labs.tu-berlin.de> <4303ADEB-89E3-4AAB-99B8-F22BE1C95E55@apple.com> Date: Mon, 28 Oct 2013 19:10:53 -0700 Message-ID: From: Yoshifumi Nishida To: Rui Paulo Content-Type: multipart/alternative; boundary=089e01176915ec708f04e9d7b96a Cc: multipathtcp Subject: Re: [multipathtcp] new version of draft-khalili-mptcp-congestion-control X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 02:11:02 -0000 --089e01176915ec708f04e9d7b96a Content-Type: text/plain; charset=ISO-8859-1 Hi Rui, On Mon, Oct 28, 2013 at 4:46 PM, Rui Paulo wrote: > On 22 Oct 2013, at 10:50, Yoshifumi Nishida > wrote: > > I think we will need to re-charter if we want to proceed this. Please > let us know if you have comments on this. > > Hmm, really? There is already a (apparently broken) MPTCP congestion > control RFC. Why do we need to re-charter to improve on it? > Hmm. I don't think I saw the info that the current MPTCP congestion control is broken. It would be good if you could list the pointer for it. I've read the Ramin's draft (draft-khalili-mptcp-performance-issues), but I think we will need to discuss how the scenarios in the draft are crucial. BTW, I'm inclined to think your comment as showing support on the draft. Am I wrong? -- Yoshifumi --089e01176915ec708f04e9d7b96a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Rui,

On Mon, Oct 28, 2013 at 4:46 PM, Rui Paulo <= ;rpaulo@apple.com= > wrote:
On 22 Oct 2013, at 10:50, Yoshifumi Nish= ida <nishida@sfc.wide.ad.jp> wrote:
> I think we will need to re-charter if we want to proceed this. Please = let us know if you have comments on this.

Hmm, really? There is already a (apparently broken) MPTCP congestion = control RFC. Why do we need to re-charter to improve on it?

Hmm. =A0I don't think I saw the info that the curr= ent MPTCP congestion control is broken.
It would be good if you could list the pointer for it.
I'= ;ve read the Ramin's draft (draft-khalili-mptcp-performance-issues), bu= t I think we will need to discuss how the scenarios in the draft are crucia= l.

BTW, I'm inclined to think your comment as showing = support on the draft. Am I wrong?
--
Yoshifumi




--089e01176915ec708f04e9d7b96a-- From ramin@net.t-labs.tu-berlin.de Tue Oct 29 04:09:04 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 4054121F9EED for ; Tue, 29 Oct 2013 04:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.742, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdW-5H0DOopH for ; Tue, 29 Oct 2013 04:09:03 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id D437E21F9EC8 for ; Tue, 29 Oct 2013 04:08:52 -0700 (PDT) Received: from [130.149.220.44] (ramin.net.t-labs.tu-berlin.de [130.149.220.44]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 2CD69802E7; Tue, 29 Oct 2013 12:08:51 +0100 (CET) Message-ID: <526F973B.2000602@net.t-labs.tu-berlin.de> Date: Tue, 29 Oct 2013 12:08:43 +0100 From: Ramin Khalili User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Yoshifumi Nishida , Rui Paulo References: <52665129.8030509@net.t-labs.tu-berlin.de> <4303ADEB-89E3-4AAB-99B8-F22BE1C95E55@apple.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090603000407040503050007" Cc: multipathtcp Subject: Re: [multipathtcp] new version of draft-khalili-mptcp-congestion-control X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 11:09:04 -0000 This is a multi-part message in MIME format. --------------090603000407040503050007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yoshifumi, Based on our results, we can argue that the current congestion control of MPTCP does not provide any better load-balancing/congestion-balancing than using Uncoupled NewReno (where regular TCP congestion control is used on the subflows). I could not say that it is completely broken but it does not do its job. As an alternative exist that does the job, and as it is already part of the MPTCP implementation, I do not see any reason why we should not discuss about it. Cheers, Ramin. Am 29.10.2013 03:10, schrieb Yoshifumi Nishida: > Hi Rui, > > On Mon, Oct 28, 2013 at 4:46 PM, Rui Paulo > wrote: > > On 22 Oct 2013, at 10:50, Yoshifumi Nishida > > wrote: > > I think we will need to re-charter if we want to proceed this. > Please let us know if you have comments on this. > > Hmm, really? There is already a (apparently broken) MPTCP > congestion control RFC. Why do we need to re-charter to improve on it? > > > Hmm. I don't think I saw the info that the current MPTCP congestion > control is broken. > It would be good if you could list the pointer for it. > I've read the Ramin's draft (draft-khalili-mptcp-performance-issues), > but I think we will need to discuss how the scenarios in the draft are > crucial. > > BTW, I'm inclined to think your comment as showing support on the > draft. Am I wrong? > -- > Yoshifumi > > > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --------------090603000407040503050007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Yoshifumi,

Based on our results, we can argue that the current congestion control of MPTCP does not provide any better load-balancing/congestion-balancing than using Uncoupled NewReno (where regular TCP congestion control is used on the subflows). I could not say that it is completely broken but it does not do its job.

As an alternative exist that does the job, and as it is already part of the MPTCP implementation, I do not see any reason why we should not discuss about it.

Cheers,
Ramin.


Am 29.10.2013 03:10, schrieb Yoshifumi Nishida:
Hi Rui,

On Mon, Oct 28, 2013 at 4:46 PM, Rui Paulo <rpaulo@apple.com> wrote:
On 22 Oct 2013, at 10:50, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
> I think we will need to re-charter if we want to proceed this. Please let us know if you have comments on this.

Hmm, really? There is already a (apparently broken) MPTCP congestion control RFC. Why do we need to re-charter to improve on it?

Hmm.  I don't think I saw the info that the current MPTCP congestion control is broken.
It would be good if you could list the pointer for it.
I've read the Ramin's draft (draft-khalili-mptcp-performance-issues), but I think we will need to discuss how the scenarios in the draft are crucial.

BTW, I'm inclined to think your comment as showing support on the draft. Am I wrong?
--
Yoshifumi






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

--------------090603000407040503050007-- From rpaulo@apple.com Tue Oct 29 09:30:13 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 370B811E81FB for ; Tue, 29 Oct 2013 09:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MA95jyeayAeK for ; Tue, 29 Oct 2013 09:30:06 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2AABD21E809E for ; Tue, 29 Oct 2013 09:29:56 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MVF00HGQV5O6XS0@mail-out.apple.com> for multipathtcp@ietf.org; Tue, 29 Oct 2013 09:29:55 -0700 (PDT) X-AuditID: 11807166-b7f8b6d000001072-df-526fe28352aa Received: from [17.153.0.89] (Unknown_Domain [17.153.0.89]) by relay8.apple.com (Apple SCV relay) with SMTP id 3E.1D.04210.382EF625; Tue, 29 Oct 2013 09:29:55 -0700 (PDT) From: Rui Paulo X-Mailer: iPhone Mail (11D89) In-reply-to: Date: Tue, 29 Oct 2013 09:23:17 -0700 Message-id: References: <52665129.8030509@net.t-labs.tu-berlin.de> <4303ADEB-89E3-4AAB-99B8-F22BE1C95E55@apple.com> To: Yoshifumi Nishida X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUiOJMhUrf5UX6QwecmbYvPq6+zWWxccoPN gcljyZKfTB4XX19nDmCK4rJJSc3JLEst0rdL4MqYfqefraCLtaL5+S2WBsY2li5GTg4JAROJ gz/fMEPYYhIX7q1n62Lk4hASWMMoseT0VSCHg4NZQEdi8kJGEJNXQFzi6kEfkHJhgUCJRS+e MIHYbAJKEs/6TrCDlEgIyErsa8oEMTmBSo698AOpYBFQlTh3fhsjiM0soCFx/WEzG4StLbFs 4WuwA3gFbCR+bmwEmygk8JFR4trlahBbREBP4sP3j0wTGPlnIZwzC+GcWUgGLWBkXsUoUJSa k1hpoZdYUJCTqpecn7uJERRoDYVpOxibllsdYhTgYFTi4TV4kB8kxJpYVlyZe4hRgoNZSYR3 +nGgEG9KYmVValF+fFFpTmrxIUZpDhYlcd5/HEApgfTEktTs1NSC1CKYLBMHp1QD440XK5i+ Ljyz7vR8pbfvXtbosm/of/tN5lcFM4foM2c2+/+77nO3fGKOmNW94L5oamFFw8zmXQ9uiLq8 DppwZPmVwLX17Yk/bf+a7WWbVD7Br0rq5usjXH48G48xbMnR+2ai/ar+hZTy7Ff7RV6sXTL1 5edD2prRz2bZ/FT4e2ri+2U1J440+k1VYinOSDTUYi4qTgQAzMj+pjACAAA= Cc: multipathtcp Subject: Re: [multipathtcp] new version of draft-khalili-mptcp-congestion-control X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 16:30:13 -0000 > On Oct 28, 2013, at 19:10, Yoshifumi Nishida wrote: > > Hmm. I don't think I saw the info that the current MPTCP congestion control is broken. > It would be good if you could list the pointer for it. > I've read the Ramin's draft (draft-khalili-mptcp-performance-issues), but I think we will need to discuss how the scenarios in the draft are crucial. > > BTW, I'm inclined to think your comment as showing support on the draft. Am I wrong? I was merely questioning the need to re-charter given that RFC 6356 is a product of this WG. I haven't read Ramin's draft yet so I can't comment. From nishida@sfc.wide.ad.jp Tue Oct 29 20:53:30 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 6F2A311E8202 for ; Tue, 29 Oct 2013 20:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.836 X-Spam-Level: X-Spam-Status: No, score=-101.836 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuCeV0J40i-k for ; Tue, 29 Oct 2013 20:53:30 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 7B52E11E831C for ; Tue, 29 Oct 2013 20:53:25 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 3ACC52780AF for ; Wed, 30 Oct 2013 12:53:21 +0900 (JST) Received: by mail-lb0-f175.google.com with SMTP id z5so766232lbh.34 for ; Tue, 29 Oct 2013 20:53:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GCA3jmWc9BAEsxGIRxxwKYIaRv679rat4ZzNyaRUwLE=; b=eHxnxBUXMF1h35nptOgKgmbnlyQxxkMNZQt/CQSMP8M+zlNu68ohhJiEvStbVtqLhO cGjzFgNUNy/lYuQXLg/e+qufchk2oDIncc05YmIchTg+/YurTEF9XgmBxCvhJXrU720g itigCiDh8Zzwk/QerkjlZcQ2JNIAsBQ0Ypm1wqFCPdKEALR+HKuquHH+uySutAzeAmvs YOn3SMX0HZnpUfwQ+rsEz8aiA1s1mvR8iiKzqSgfxp9L2IZDf9CzCqcxb2yTfEDl37TP akyoXzvEC9EFfF2QorMxpJPhoeJJ6K4mfcXgOy0yV4LpDPZJseAAi6e7HRIaIGn/5XPj 078g== MIME-Version: 1.0 X-Received: by 10.112.149.197 with SMTP id uc5mr2012115lbb.19.1383105199606; Tue, 29 Oct 2013 20:53:19 -0700 (PDT) Received: by 10.114.99.99 with HTTP; Tue, 29 Oct 2013 20:53:19 -0700 (PDT) In-Reply-To: References: <52665129.8030509@net.t-labs.tu-berlin.de> <4303ADEB-89E3-4AAB-99B8-F22BE1C95E55@apple.com> Date: Tue, 29 Oct 2013 20:53:19 -0700 Message-ID: From: Yoshifumi Nishida To: Rui Paulo Content-Type: multipart/alternative; boundary=047d7b343cd21c111104e9ed46dd Cc: multipathtcp Subject: Re: [multipathtcp] new version of draft-khalili-mptcp-congestion-control 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, 30 Oct 2013 03:53:30 -0000 --047d7b343cd21c111104e9ed46dd Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 29, 2013 at 9:23 AM, Rui Paulo wrote: > > > On Oct 28, 2013, at 19:10, Yoshifumi Nishida > wrote: > > > > Hmm. I don't think I saw the info that the current MPTCP congestion > control is broken. > > It would be good if you could list the pointer for it. > > I've read the Ramin's draft (draft-khalili-mptcp-performance-issues), > but I think we will need to discuss how the scenarios in the draft are > crucial. > > > > BTW, I'm inclined to think your comment as showing support on the draft. > Am I wrong? > > I was merely questioning the need to re-charter given that RFC 6356 is a > product of this WG. I haven't read Ramin's draft yet so I can't comment. > I see. Just to be clear. Of course, we can have random discussions on RFC6356 or Ramin's draft. But, we cannot make consensus or publishing a document as an WG product if it is not on the charter. -- Yoshifumi --047d7b343cd21c111104e9ed46dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Tue, Oct 29, 2013 at 9:23 AM, Rui Paulo <rpaulo@apple.com>= wrote:

> On Oct 28, 2013, at 19:10, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
>
> Hmm. =A0I don't think I saw the info that the current MPTCP conges= tion control is broken.
> It would be good if you could list the pointer for it.
> I've read the Ramin's draft (draft-khalili-mptcp-performance-i= ssues), but I think we will need to discuss how the scenarios in the draft = are crucial.
>
> BTW, I'm inclined to think your comment as showing support on the = draft. Am I wrong?

I was merely questioning the need to re-charter given that RFC 6356 i= s a product of this WG. I haven't read Ramin's draft yet so I can&#= 39;t comment.

I see.=A0
Just to be clear. Of course, we can have random disc= ussions on RFC6356 or Ramin's draft.
Bu= t, we cannot make consensus or publishing a document as an WG product if it= is not on the charter.
--
Yoshifumi




=
--047d7b343cd21c111104e9ed46dd-- From nishida@sfc.wide.ad.jp Tue Oct 29 22:59:58 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 218CC11E80F6 for ; Tue, 29 Oct 2013 22:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.85 X-Spam-Level: X-Spam-Status: No, score=-101.85 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybSWjKs5M2NE for ; Tue, 29 Oct 2013 22:59:57 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 7642E11E80E6 for ; Tue, 29 Oct 2013 22:59:56 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E7FF22780BC for ; Wed, 30 Oct 2013 14:59:53 +0900 (JST) Received: by mail-lb0-f172.google.com with SMTP id c11so824946lbj.17 for ; Tue, 29 Oct 2013 22:59:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=yOHhiirMMbYd6QhkPgTh67M8b1mtDyrDFeBHCN6AMzY=; b=fQS68pZrQ7F5658iccchBCABHm+6/MPrHoEDEWjOSTAQtsBjpz8jcIInZiZ3kLeQjb DjFNF6bur3TjAvvva9HWmCCx0dIyvvKVTdf6CrFEHBvqBsqVp6ng9s/zgabOF0scbnVX 3XwwfZSIDZHbJ10pHEPVfa+EsExJ8+1xDFoSm011rOpSHW9ONeoMujB4NV5pTNk/woGL txB7/Et1hzTKAGf4tZ6gOEsid0j9fHfOHHyEfk1RQVMZ8O1J8Cn/NqdoTw1wx0ooAdG3 sGozXTreXM/jljIpNhuxVyHB+DwXszNW43em0vb4zx7HHzloxUdEQveSwDdRB0mkao/l 1r8Q== MIME-Version: 1.0 X-Received: by 10.152.22.97 with SMTP id c1mr373545laf.31.1383112791236; Tue, 29 Oct 2013 22:59:51 -0700 (PDT) Received: by 10.114.99.99 with HTTP; Tue, 29 Oct 2013 22:59:51 -0700 (PDT) Date: Tue, 29 Oct 2013 22:59:51 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=089e0158b86a9b272204e9ef0a2a Subject: [multipathtcp] draft agenda for vancouver meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 05:59:58 -0000 --089e0158b86a9b272204e9ef0a2a Content-Type: text/plain; charset=ISO-8859-1 Sorry for the delayed announce. You can find the current draft agenda in the following URL. http://www.ietf.org/proceedings/88/agenda/agenda-88-mptcp Thanks, -- Yoshi & Phil --089e0158b86a9b272204e9ef0a2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sorry for the delayed announce.
You can fin= d the current draft agenda in the following URL.

http://www.= ietf.org/proceedings/88/agenda/agenda-88-mptcp

Thanks,
--
Yoshi & Phil
--089e0158b86a9b272204e9ef0a2a-- From rpaulo@apple.com Wed Oct 30 10:09:23 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 4AE9D11E81D5 for ; Wed, 30 Oct 2013 10:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5AgH6tMYwAk for ; Wed, 30 Oct 2013 10:09:07 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7461C11E819D for ; Wed, 30 Oct 2013 10:08:19 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MVH00GU1RLO0B12@mail-out.apple.com> for multipathtcp@ietf.org; Wed, 30 Oct 2013 10:08:19 -0700 (PDT) X-AuditID: 11807143-b7fbb6d00000049d-ed-52713d03cf99 Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 4B.BA.01181.30D31725; Wed, 30 Oct 2013 10:08:19 -0700 (PDT) Received: from rui-macbook-pro.apple.com ([17.193.13.39]) by sesame.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MVH00JCPRLUTC90@sesame.apple.com> for multipathtcp@ietf.org; Wed, 30 Oct 2013 10:08:18 -0700 (PDT) From: Rui Paulo In-reply-to: Date: Wed, 30 Oct 2013 10:08:18 -0700 Content-transfer-encoding: quoted-printable Message-id: <3CAEE72A-0E6F-461B-BE63-ABEB662BA0BF@apple.com> References: <52665129.8030509@net.t-labs.tu-berlin.de> <4303ADEB-89E3-4AAB-99B8-F22BE1C95E55@apple.com> To: Yoshifumi Nishida , philip.eardley@bt.com X-Mailer: Apple Mail (2.1816) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDcoMtsWxhkMP2BgMXn1dfZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsbX/BXvBbo6Kx68fszcwPmTrYuTkkBAwkTh5dTUThC0mceHe eqA4F4eQQB+TxKwj91ggnCVMEh8+PwZyODiYBfQk7l/UAmngBTKPnnkN1iwsECzxfH0vK4jN JqAk8azvBDuIzQkUX3TmHwuIzSKgKrH89FawGmYBDYnrD5vZIGxtiSfvLrBCzLSR2DDnJNTe j0wSv+dfBBskIuAqcfzULFaIS2UlJv49wTiBUWAWwkmzkJw0C8nYBYzMqxgFilJzEiuN9BIL CnJS9ZLzczcxggOv0HkH47FlVocYBTgYlXh4GXQLg4RYE8uKK3MPMUpwMCuJ8OoZA4V4UxIr q1KL8uOLSnNSiw8xSnOwKInzyvoVBAkJpCeWpGanphakFsFkmTg4pRoYZ/xvfX1fIJ27p+rw ntoZvMvUcxKkPoQtKhIVuO5aYui38PPm9J6TM2L/v5hweatF5Y6JX4qLFb3r9ijJFKvNUfK7 sJlLU1Vx0XOOzKfd6zq3mJVozw79EF14QHzXR4M7J31spraHiTU92fvt3IOdGvrmB9a9XlO7 /G/574ly9TIS0iLRvzesVmIpzkg01GIuKk4EAKoOYt44AgAA Cc: multipathtcp Subject: Re: [multipathtcp] new version of draft-khalili-mptcp-congestion-control 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, 30 Oct 2013 17:09:24 -0000 On 29 Oct 2013, at 20:53, Yoshifumi Nishida = wrote: > Just to be clear. Of course, we can have random discussions on RFC6356 = or Ramin's draft. > But, we cannot make consensus or publishing a document as an WG = product if it is not on the charter. Are you saying that Ramin=92s draft (which, as I understand it, is an = improvement of RFC 6356) does not fall under the initial WG charter = section c) ? Specifically: "c. A coupled multipath-aware congestion control algorithm. This = algorithm is the multipath equivalent of SACK/NewReno congestion = control.=94 I=92m sure there=92s something I=92m missing, but I=92m trying to = understand why this WG can=92t publish MPTCP congestion control = documents without a new charter. What=92s even more confusing to me is = that we already published a congestion control algorithm with the = initial charter. If we indeed have to re-charter to work on MPTCP congestion control = algorithms, I=92d love to know what the WG chairs think about this. Thanks, -- Rui Paulo From philip.eardley@bt.com Wed Oct 30 11:07: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 CCDB111E818B for ; Wed, 30 Oct 2013 11:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.127 X-Spam-Level: X-Spam-Status: No, score=-103.127 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WORgVyIzVVZz for ; Wed, 30 Oct 2013 11:07:40 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 6CED321E8135 for ; Wed, 30 Oct 2013 11:05:06 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 30 Oct 2013 18:04:45 +0000 Received: from EMV67-UKRD.domain1.systemhost.net ([169.254.2.147]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Wed, 30 Oct 2013 18:04:45 +0000 From: To: , Date: Wed, 30 Oct 2013 18:04:44 +0000 Thread-Topic: [multipathtcp] new version of draft-khalili-mptcp-congestion-control Thread-Index: Ac7VkqOdLh6KzlGlSpOxNYrr3rroVQAB7Ozw Message-ID: References: <52665129.8030509@net.t-labs.tu-berlin.de> <4303ADEB-89E3-4AAB-99B8-F22BE1C95E55@apple.com> <3CAEE72A-0E6F-461B-BE63-ABEB662BA0BF@apple.com> In-Reply-To: <3CAEE72A-0E6F-461B-BE63-ABEB662BA0BF@apple.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] new version of draft-khalili-mptcp-congestion-control 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, 30 Oct 2013 18:07:44 -0000 Rui Please see http://www.ietf.org/mail-archive/web/multipathtcp/current/msg020= 88.html Best wishes Phil > -----Original Message----- > From: Rui Paulo [mailto:rpaulo@apple.com] > Sent: 30 October 2013 17:08 > To: Yoshifumi Nishida; Eardley,PL,Philip,TUB8 R > Cc: multipathtcp > Subject: Re: [multipathtcp] new version of draft-khalili-mptcp- > congestion-control >=20 > On 29 Oct 2013, at 20:53, Yoshifumi Nishida > wrote: > > Just to be clear. Of course, we can have random discussions on > RFC6356 or Ramin's draft. > > But, we cannot make consensus or publishing a document as an WG > product if it is not on the charter. >=20 > Are you saying that Ramin's draft (which, as I understand it, is an > improvement of RFC 6356) does not fall under the initial WG charter > section c) ? >=20 > Specifically: >=20 > "c. A coupled multipath-aware congestion control algorithm. This > algorithm is the multipath equivalent of SACK/NewReno congestion > control." >=20 > I'm sure there's something I'm missing, but I'm trying to understand > why this WG can't publish MPTCP congestion control documents without a > new charter. What's even more confusing to me is that we already > published a congestion control algorithm with the initial charter. >=20 > If we indeed have to re-charter to work on MPTCP congestion control > algorithms, I'd love to know what the WG chairs think about this. >=20 > Thanks, > -- > Rui Paulo >=20 >=20 From christoph.paasch@uclouvain.be Wed Oct 30 11:58:56 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 3228011E8192 for ; Wed, 30 Oct 2013 11:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QT7Qs2uNi2Ul for ; Wed, 30 Oct 2013 11:58:51 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id A5B7311E818E for ; Wed, 30 Oct 2013 11:58:38 -0700 (PDT) Received: from localhost (unknown [172.17.0.12]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 6D5A6183414 for ; Wed, 30 Oct 2013 19:58:30 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 6D5A6183414 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1383159510; bh=qi9VQp5P17QLvSH1zdw2o6w7jz6xd+KkYUmrXBEGk5c=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=vMy2Mf5FZzYisjzBJpmtG0kbZYEH8u2GMv77xdjPm4NAtphso2hW7Apnfk3/hJadG WoK3WFnM4R03Whcknexnt7L2WFDXv0pgv9NylhbVy6yZTRRCARgkYvWIVWPQtq5fgP uRujX6tMTYUfOBIS2S/n2N9XkKl6QxbxRhXb9zBg= Date: Wed, 30 Oct 2013 19:58:30 +0100 From: Christoph Paasch To: MultiPath TCP - IETF WG Message-ID: <20131030185830.GG4943@cpaasch-mac> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 6D5A6183414.ADC95 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Subject: [multipathtcp] Linux Kernel MPTCP stable release - v0.88 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, 30 Oct 2013 18:58:56 -0000 Hello all, as the IETF'88-meeting will start next week, we are happy to announce a new stable release of the Linux Kernel implementation of Multipath TCP. To download the source, or install pre-compiled Debian/Ubuntu-packages, please visit: http://multipath-tcp.org/pmwiki.php?n=Main.Release88 What is new in this release? ============================ The MPTCP v0.88 release is based on Linux Kernel v3.11. Mainly cleanup has been done on this release, compared to the previous v0.87: * Allow compiling with TCP_SYNCOOKIES and TCP_MD5SIG-option * Modularized path-manager: The path-manager is now a loadable module, which allows to have a better-structured code and it is more easy to extend/add a path-manager. * You can configure the used path-manager through the sysctl net.mptcp.mptcp_path_manager * You have the choice between: * 'default': This path-manager actually does not do anything. The host won't announce different IP-addresses nor initiate the creation of new subflows. However, it will accept the passive creation of new subflows. This path-manager might be usefull if you want to run it on a single-homed public server who is expected to receive incoming connection-requests from MPTCP-enabled clients. * 'fullmesh': This path-manager is the same as the path-manager of the previous release. It will create a full-mesh of subflows among all available subflows. * 'ndiffports': This one will create X subflows across the same pair of IP-addresses, modifying the source-port. To control the number of subflows (X), you can set the sysctl net.mptcp.mptcp_ndiffports to a value > 1. * Tons of cleanup and bug-fixes. Cheers, Christoph From nishida@sfc.wide.ad.jp Wed Oct 30 20:50:41 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 282C211E81FA for ; Wed, 30 Oct 2013 20:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.861 X-Spam-Level: X-Spam-Status: No, score=-101.861 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qW6bFFlb+Z+x for ; Wed, 30 Oct 2013 20:50:40 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 6571211E830B for ; Wed, 30 Oct 2013 20:50:39 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C31452780A0 for ; Thu, 31 Oct 2013 12:50:37 +0900 (JST) Received: by mail-lb0-f171.google.com with SMTP id x18so1936163lbi.16 for ; Wed, 30 Oct 2013 20:50:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vslbh/Bi28BNVPJigGWyiFVcSS8vBxAQccHNgEMtFbk=; b=j6zdQmgxnzjvhIrhDozWli2ct732MELaVMYNYizjbZcT0jM2k5djTOX/0tKFlRcyhD bQBomSoyQ1kU3vIvxNv8L7uQkplVhfsXtQoAkTMqpTExnJGZB8Kh8t9K//9Kg105fPSN H96n0ck3bilrb36VSr80/ft4ez2z/usuK61fSCIb0kXBmHCbdWNHNH1rE44utO+aMqv7 QKrBZ107T+civzCL2V1Cf81PLnefGwUruS5VaXtfs99jFAI7SxbHCHbcW2Zn9rO7QnQR igM4C/yQLbIsWswYJJrxi0v3L2VOI8RCM21TCs0vEndve/Gz0k1OjuV00TUW4QpGiRSP 4HcQ== MIME-Version: 1.0 X-Received: by 10.152.18.201 with SMTP id y9mr32564lad.57.1383191435455; Wed, 30 Oct 2013 20:50:35 -0700 (PDT) Received: by 10.114.99.99 with HTTP; Wed, 30 Oct 2013 20:50:35 -0700 (PDT) In-Reply-To: <3CAEE72A-0E6F-461B-BE63-ABEB662BA0BF@apple.com> References: <52665129.8030509@net.t-labs.tu-berlin.de> <4303ADEB-89E3-4AAB-99B8-F22BE1C95E55@apple.com> <3CAEE72A-0E6F-461B-BE63-ABEB662BA0BF@apple.com> Date: Wed, 30 Oct 2013 20:50:35 -0700 Message-ID: From: Yoshifumi Nishida To: Rui Paulo Content-Type: multipart/alternative; boundary=089e0141a02c2ab22e04ea015a56 Cc: multipathtcp Subject: Re: [multipathtcp] new version of draft-khalili-mptcp-congestion-control 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 Oct 2013 03:50:41 -0000 --089e0141a02c2ab22e04ea015a56 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Rui, On Wed, Oct 30, 2013 at 10:08 AM, Rui Paulo wrote: > On 29 Oct 2013, at 20:53, Yoshifumi Nishida > wrote: > > Just to be clear. Of course, we can have random discussions on RFC6356 > or Ramin's draft. > > But, we cannot make consensus or publishing a document as an WG product > if it is not on the charter. > > Are you saying that Ramin=92s draft (which, as I understand it, is an > improvement of RFC 6356) does not fall under the initial WG charter secti= on > c) ? Well, the section is a part to describe the previous charter.. I think you won't see congestion control related words in the part to describe new charter. > I=92m sure there=92s something I=92m missing, but I=92m trying to underst= and why > this WG can=92t publish MPTCP congestion control documents without a new > charter. What=92s even more confusing to me is that we already published = a > congestion control algorithm with the initial charter. > > If we indeed have to re-charter to work on MPTCP congestion control > algorithms, I=92d love to know what the WG chairs think about this. > Putting a topic in the charter means we will have to set milestone for it. Otherwise, evaluating the progress might be difficult, which is not good thing for the WG. Hence, WG chairs sometimes omit a certain topics from the charter which seems to be less attractive. But, I also think re-chartering for adding a certain topic is fairly easy for the WG as long as there is consensus. We can start the procedure if that's the consensus. Thanks, -- Yoshifumi --089e0141a02c2ab22e04ea015a56 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Rui,

On Wed, Oct 30, 2013 at 10:08 AM, Rui Paulo &l= t;rpaulo@apple.com> wrote:
On 29 Oct 2013, at 20:53, Yoshifumi Nish= ida <nishida@sfc.wide.ad.jp> wrote:
> Just to be clear. Of course, we can have random discussions on RFC6356= or Ramin's draft.
> But, we cannot make consensus or publishing a document as an WG produc= t if it is not on the charter.

Are you saying that Ramin=92s draft (which, as I understand it, is an= improvement of RFC 6356) does not fall under the initial WG charter sectio= n c) ?

I think you won't see = congestion control related words in the part to describe new charter.
=A0
I=92m sure there=92s something I=92m missing, but I=92m trying to understan= d why this WG can=92t publish MPTCP congestion control documents without a = new charter. What=92s even more confusing to me is that we already publishe= d a congestion control algorithm with the initial charter.

If we indeed have to re-charter to work on MPTCP congestion control algorit= hms, I=92d love to know what the WG chairs think about this.

Putting a topic in the charter means we will have to = set milestone for it. Otherwise, evaluating the progress might be difficult= , which is not good thing for the WG.
Hence, WG chairs sometimes omit a certain topics from the charter whic= h seems to be less attractive.

But, I also think r= e-chartering for adding a certain topic is fairly easy for the WG as long a= s there is consensus. We can start the procedure if that's the consensu= s.

Thanks,
--
Yoshifumi

=


--089e0141a02c2ab22e04ea015a56-- From ramin@net.t-labs.tu-berlin.de Thu Oct 31 07:05:15 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 49EDB21F8411 for ; Thu, 31 Oct 2013 07:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJLwdauKFK0V for ; Thu, 31 Oct 2013 07:05:12 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCB021F9D3E for ; Thu, 31 Oct 2013 07:05:11 -0700 (PDT) Received: from [130.149.220.44] (ramin.net.t-labs.tu-berlin.de [130.149.220.44]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id B427480025; Thu, 31 Oct 2013 15:05:08 +0100 (CET) Message-ID: <52726386.8070606@net.t-labs.tu-berlin.de> Date: Thu, 31 Oct 2013 15:04:54 +0100 From: Ramin Khalili User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Yoshifumi Nishida , Rui Paulo References: <52665129.8030509@net.t-labs.tu-berlin.de> <4303ADEB-89E3-4AAB-99B8-F22BE1C95E55@apple.com> <3CAEE72A-0E6F-461B-BE63-ABEB662BA0BF@apple.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010401000208080409080902" Cc: multipathtcp Subject: Re: [multipathtcp] new version of draft-khalili-mptcp-congestion-control 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 Oct 2013 14:05:15 -0000 This is a multi-part message in MIME format. --------------010401000208080409080902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Yoshifumi, What are the typical milestones for a topic like congestion control? I am asking as many practical milestones, such as implementation, debugging, integration into the UCLouvain'S MPTCP implementation, and performance evaluation (on many difference settings) are already done for our algorithm. Cheers, Ramin. Am 31.10.2013 04:50, schrieb Yoshifumi Nishida: > Hi Rui, > > On Wed, Oct 30, 2013 at 10:08 AM, Rui Paulo > wrote: > > On 29 Oct 2013, at 20:53, Yoshifumi Nishida > > wrote: > > Just to be clear. Of course, we can have random discussions on > RFC6356 or Ramin's draft. > > But, we cannot make consensus or publishing a document as an WG > product if it is not on the charter. > > Are you saying that Ramin's draft (which, as I understand it, is > an improvement of RFC 6356) does not fall under the initial WG > charter section c) ? > > > Well, the section is a part to describe the previous charter.. > I think you won't see congestion control related words in the part to > describe new charter. > > I'm sure there's something I'm missing, but I'm trying to > understand why this WG can't publish MPTCP congestion control > documents without a new charter. What's even more confusing to me > is that we already published a congestion control algorithm with > the initial charter. > > If we indeed have to re-charter to work on MPTCP congestion > control algorithms, I'd love to know what the WG chairs think > about this. > > > Putting a topic in the charter means we will have to set milestone for > it. Otherwise, evaluating the progress might be difficult, which is > not good thing for the WG. > Hence, WG chairs sometimes omit a certain topics from the charter > which seems to be less attractive. > > But, I also think re-chartering for adding a certain topic is fairly > easy for the WG as long as there is consensus. We can start the > procedure if that's the consensus. > > Thanks, > -- > Yoshifumi > > > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --------------010401000208080409080902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Yoshifumi,

What are the typical milestones for a topic like congestion control? I am asking as many practical milestones, such as implementation, debugging, integration into the UCLouvain'S MPTCP implementation, and performance evaluation (on many difference settings) are already done for our algorithm.

Cheers,
Ramin.

Am 31.10.2013 04:50, schrieb Yoshifumi Nishida:
--------------010401000208080409080902-- From nishida@sfc.wide.ad.jp Thu Oct 31 20:46:13 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 C393021F8423 for ; Thu, 31 Oct 2013 20:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.879 X-Spam-Level: X-Spam-Status: No, score=-101.879 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLuwiHMTk1vn for ; Thu, 31 Oct 2013 20:46:13 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id EE55621F9302 for ; Thu, 31 Oct 2013 20:46:07 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id DF1DE278099 for ; Fri, 1 Nov 2013 12:45:51 +0900 (JST) Received: by mail-la0-f44.google.com with SMTP id ep20so3013033lab.31 for ; Thu, 31 Oct 2013 20:45:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6B4fkQNZusBG7VYf4fBX97hXRbX/FU9JWKg349jqDaI=; b=GB8rpJdBT2zNvQps6y2CINFJU1vBau6soPl/FDugJvGeHZzwVQ5sb4DeRNwsdDZS1s OLVM4aG/09q9WTAffhuI9VcJVZyhrWTvc5zSQD0ZQ1xpn5Z2EGXUjYF45lMKx5jY/Hsn 0ai3MIVV32pG7A8ybv6WSSGlyxmH2m3Zgu3AyLGe/OVK+7ZeCc/WcbO/c66VXVq5YLuy 7MKgrLjb8O/krpy5d6bRFLOZXtHyjvXk7A5qqrGXzSogHvE6wHi/ZNPi6T5YHe/vgWpH ElqkA+XBEwvFpPLopgeafm4XUazzMb+cdxJ+xtIeQF0Nntf3nI3n605WHKXE+rEh1oKo PDRw== MIME-Version: 1.0 X-Received: by 10.112.128.166 with SMTP id np6mr532351lbb.7.1383277549327; Thu, 31 Oct 2013 20:45:49 -0700 (PDT) Received: by 10.114.99.99 with HTTP; Thu, 31 Oct 2013 20:45:49 -0700 (PDT) In-Reply-To: <52726386.8070606@net.t-labs.tu-berlin.de> References: <52665129.8030509@net.t-labs.tu-berlin.de> <4303ADEB-89E3-4AAB-99B8-F22BE1C95E55@apple.com> <3CAEE72A-0E6F-461B-BE63-ABEB662BA0BF@apple.com> <52726386.8070606@net.t-labs.tu-berlin.de> Date: Thu, 31 Oct 2013 20:45:49 -0700 Message-ID: From: Yoshifumi Nishida To: Ramin Khalili Content-Type: multipart/alternative; boundary=047d7b343ef2f41d2a04ea1566fe Cc: multipathtcp Subject: Re: [multipathtcp] new version of draft-khalili-mptcp-congestion-control 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, 01 Nov 2013 03:46:13 -0000 --047d7b343ef2f41d2a04ea1566fe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ramin, I'm not sure if these are typical topics, but I'm guessing it might be analysis and evaluation for the current algorithm or new algorithm spec. Anyway, it will be decided by the consensus. -- Yoshifumi On Thu, Oct 31, 2013 at 7:04 AM, Ramin Khalili < ramin@net.t-labs.tu-berlin.de> wrote: > Hi Yoshifumi, > > What are the typical milestones for a topic like congestion control? I am > asking as many practical milestones, such as implementation, debugging, > integration into the UCLouvain'S MPTCP implementation, and performance > evaluation (on many difference settings) are already done for our algorit= hm. > > Cheers, > Ramin. > > Am 31.10.2013 04:50, schrieb Yoshifumi Nishida: > > Hi Rui, > > On Wed, Oct 30, 2013 at 10:08 AM, Rui Paulo wrote: > >> On 29 Oct 2013, at 20:53, Yoshifumi Nishida >> wrote: >> > Just to be clear. Of course, we can have random discussions on RFC6356 >> or Ramin's draft. >> > But, we cannot make consensus or publishing a document as an WG produc= t >> if it is not on the charter. >> >> Are you saying that Ramin=92s draft (which, as I understand it, is an >> improvement of RFC 6356) does not fall under the initial WG charter sect= ion >> c) ? > > > Well, the section is a part to describe the previous charter.. > I think you won't see congestion control related words in the part to > describe new charter. > > >> I=92m sure there=92s something I=92m missing, but I=92m trying to unders= tand why >> this WG can=92t publish MPTCP congestion control documents without a new >> charter. What=92s even more confusing to me is that we already published= a >> congestion control algorithm with the initial charter. >> >> If we indeed have to re-charter to work on MPTCP congestion control >> algorithms, I=92d love to know what the WG chairs think about this. >> > > Putting a topic in the charter means we will have to set milestone for > it. Otherwise, evaluating the progress might be difficult, which is not > good thing for the WG. > Hence, WG chairs sometimes omit a certain topics from the charter which > seems to be less attractive. > > But, I also think re-chartering for adding a certain topic is fairly > easy for the WG as long as there is consensus. We can start the procedure > if that's the consensus. > > Thanks, > -- > Yoshifumi > > > > > > _______________________________________________ > multipathtcp mailing listmultipathtcp@ietf.orghttps://www.ietf.org/mailma= n/listinfo/multipathtcp > > > --047d7b343ef2f41d2a04ea1566fe Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Ramin,

I'm not sure if these are= typical topics, but I'm guessing it might be analysis and evaluation f= or the current algorithm or new algorithm spec. Anyway, it will be decided = by the consensus.
--
Yoshifumi

=
On Thu, Oct 31, 2013 at 7:04 AM, Ramin Khali= li <ramin@net.t-labs.tu-berlin.de> wrote:
=20 =20 =20
Hi Yoshifumi,

What are the typical milestones for a topic like congestion control? I am asking as many practical milestones, such as implementation, debugging, integration into the UCLouvain'S MPTCP implementation, and performance evaluation (on many difference settings) are already done for our algorithm.

Cheers,
Ramin.

Am 31.10.2013 04:50, schrieb Yoshifumi Nishida:
Hi Rui,

On Wed, Oct 30, 2013 at 10:08 AM, Rui Paulo <rpaulo@apple.com> wrote:
On 29 Oct 2013, at 20:53, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
> Just to be clear. Of course, we can have random discussions on RFC6356 or Ramin's draft.
> But, we cannot make consensus or publishing a document as an WG product if it is not on the charter.

Are you saying that Ramin=92s draft (which, as I understand it, is an improvement of RFC 6356) does not fall under the initial WG charter section c) ?

Well, the section is a part to describe the previous charter..
I think you won't see congestion control related words in the part to describe new charter.
=A0
I=92m sure there=92s something I=92m missing, but I=92m trying to understand why this WG can=92t publish MPTCP congestion control documents without a new charter. What=92s even more confusing to me is that we already published a congestion control algorithm with the initial charter.

If we indeed have to re-charter to work on MPTCP congestion control algorithms, I=92d love to know what the WG chairs think about this.

Putting a topic in the charter means we will have to set milestone for it. Otherwise, evaluating the progress might be difficult, which is not good thing for the WG.
Hence, WG chairs sometimes omit a certain topics from the charter which seems to be less attractive.

But, I also think re-chartering for adding a certain topic is fairly easy for the WG as long as there is consensus. We can start the procedure if that's the consensus.

Thanks,
--
Yoshifumi





_______________________________________________
multipathtcp mailing list
multipathtcp@iet=
f.org
https://www.ietf.org/mailman/listinfo/multipathtcp


--047d7b343ef2f41d2a04ea1566fe--
Hi Rui,

On Wed, Oct 30, 2013 at 10:08 AM, Rui Paulo <rpaulo@apple.com> wrote:
On 29 Oct 2013, at 20:53, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
> Just to be clear. Of course, we can have random discussions on RFC6356 or Ramin's draft.
> But, we cannot make consensus or publishing a document as an WG product if it is not on the charter.

Are you saying that Ramin’s draft (which, as I understand it, is an improvement of RFC 6356) does not fall under the initial WG charter section c) ?

Well, the section is a part to describe the previous charter..
I think you won't see congestion control related words in the part to describe new charter.
 
I’m sure there’s something I’m missing, but I’m trying to understand why this WG can’t publish MPTCP congestion control documents without a new charter. What’s even more confusing to me is that we already published a congestion control algorithm with the initial charter.

If we indeed have to re-charter to work on MPTCP congestion control algorithms, I’d love to know what the WG chairs think about this.

Putting a topic in the charter means we will have to set milestone for it. Otherwise, evaluating the progress might be difficult, which is not good thing for the WG.
Hence, WG chairs sometimes omit a certain topics from the charter which seems to be less attractive.

But, I also think re-chartering for adding a certain topic is fairly easy for the WG as long as there is consensus. We can start the procedure if that's the consensus.

Thanks,
--
Yoshifumi





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